Yes, that was also solved through the Csound API. Cabbage had that in place for GEN02, GEN05 and GEN07, so in the bezier branch I just added a case for the “quadbezier” GEN.
Edit: I probably misunderstood you. Send new control points to the Cabbage widget from Csound code do you mean?
Yes, if I load the control points from a preset file, then how can I make so that those control points are updated in the widget too?
In the code I attached in a previous post (LINK) I managed only to update the displayed curve (with raw values read from a file), but the control points don’t change…
I’ve been thinking about this, but I don’t think this is currently possible. Not without Cabbage saving the gen args user create when they edit a table. These could be saved to a string channel. That would be straight forward enough, and user could then grab that channel and save the string to file.
But how does one then create a function table based on a variable number of GEN args? I guess the easiest way would be a new identifier, tableargs:N("1, 0, 1024, -7, 1, 512, 0, 512, 1"), that users can call in Csound. This will then update the table points, and send the new table to Csound. Actually tableargs(tableNumber, "data") might be more readable as the N in multiple tables refers to the instance, not the table number.
Would that work ok? For example, sample code might look like this:
<Cabbage>
form caption("Untitled") size(400, 300), colour(58, 110, 182), pluginid("def1")
gentable bounds(24, 72, 363, 177), tablenumber(10), identchannel("table1")
</Cabbage>
(...)
instr 1001
/*the channel "fN_args" will retrieve the last f statement used to create table N.
Each time a user moves a handle, this channel will be updated */
STableData chnget "f10_args"
fprints "preset1.txt", "%s", STableData
endin
instr 1002
STableData, iLinNum readfi "preset1.txt"
chnset STableData, "table1"
endinQuestion: Does changing the tablenumber (i.e., chnset “tablenumber(1122)”, “table1”) on the fly works? I might have a solution for all this if it does in a more recent Cabbage version than the one I have currently installed, in which it doesn’t.
Sorry, no. That’s not currently possible. Once you create a gentable, the table number is fixed. I can look at changing this, but I think it’s going to add a bit of overhead. Please outline your solution, I’m all ears and open to suggestions.
I was thinking about something like this:
;=================================================
instr 1000 ; WRITE THE VEL PRESET
Sargs getftargs giFT_velCurve, 1
gihand fiopen "preset1.txt", 0
iArr[], iCnt StrToArr Sargs, " "
fouti gihand, 0, 0, iCnt
$FOR_INDEX('indx' FROM '0' TO 'iCnt-1')
fouti gihand, 0, 0, iArr[indx]
$NEXT()
ficlose gihand
turnoff
endin
instr 1001 ; READ THE VEL PRESET
iTemp = 0
Stmp init ""
giHand fiopen "preset1.txt", 1
iCnt init -1
fini giHand, 0, 1, iCnt
$FOR_INDEX('indx' FROM '0' TO 'iCnt - 1')
fini giHand, 0, 1, iTemp
Stemp = Stmp
Stmp sprintf "%s %d", Stemp, iTemp
$NEXT()
ficlose giHand
Sscoreline sprintf "f 1111 0 %d -7 %s", giVelCurveRes, Stmp
scoreline_i Sscoreline
chnset "tablenumber(1111)", "table1"
turnoff
endin
The idea was to change to a dummy f-table before calling the scoreline opcode. But anyways shouldn’t something like this work?
Gees, I totally forgot about the getftargs opcode. (Sorry, I see now you linked it earlier). In that case all the pieces are there. We don’t need to dynamically update the table number at all. Just call tablenumber() with the same table as the one created with scoreline. Or am I missing something?
It isn’t working with the Cabbage version I’ve installed. First of all I’m seeing some discrepancies between y-values in the widget and what the getftarg opcode retrieves. I think this is because some rounding that was necessary for dealing with the pixels.
But I’m also seeing some extra 1s at the end of the table after I add a new point with the mouse. The original size of the table is 1024, but it ends up at 1025 or 1026.
EDIT: On a more recent Cabbage I found the values add up to 1025. Maybe the guard point?
But exactly what chnset "tablenumber(1111)", "table1" does? It seems to me the it just makes the widget redraw its contents based on its internal array, so it would not be sufficient to do that.
So @gsenna idea was to force Cabbage to update the control points too by creating a new score event… I don’t know if it could work but in the last Csound that I built today from the sources, the parser doesn’t even recognize the ‘getftargs’ token… 
Most likely. You’re right about rounding errors and pixels. It’s a pain, but what can one do? This can never be a high precision operation.
It reloads the gentable widget to show the most recent version of table 1111. This will update handles too, if the gen args are not the same as the original. @gsenna, do you have it working now? You must be close?
@mauro, you probably need to set OPCODE6DIR64 to point to the location of your opcode DLLS. If you renamed the original folder Csound is only loading the csound64.dll lib, and none of the plugin opcodes. On the other hand, I would have assumed getftargs is part of csound64.dll rather than a separate plugin lib?
I have a semi-working version. But each time one saves the table there is an added point for the extra guarding point. The solution would be to keep count and fout only values < giVelCurveRes.
By the way, there was an error above. One of the lines should instead be:
Stmp sprintf "%s %f", Stemp, iTemp
gerftargs was included as a separate plugin lib. It should be part of Csound since 6.08 I think. Maybe someone thought it wasn’t useful enough to include it on Windows (?).
Mauro is using his own build of Csound. I’m sure it’s just an OPCODE6DIR64 path issue.
@rorywalsh you are right… That opcode is in a plugin file and I didn’t placed them in the separated plugins64 dir (I placed all the exe and dll files inside the directory in “C:\Program Files\Csound6_x64\bin”)…
I’m not sure what’s going on. If I “save” without interacting with the widget getftargs reports 3 arguments (which is correct), but any sort of interaction -not adding, but just moving the points- with the gentable widget raises the count to 5, while repeating the last value inside the table.
@rorywalsh, can you try “saving” and moving a handle and “saving” again with the most up to date Cabbage you have?
Check for the value of iCnt printed on the console. Over here it doesn’t make sense as the interaction adds a point at the end. You can also look for that last value inside of “preset1.txt”.
works.csd (5.9 KB)
Yes, it behaves like that to me too. I have a version that works, but only if you change something in the widget before saving the preset…
I’m also seeing this. I think I know what’s happening. I haven’t checked the source yet, but if you drag the right-most handle leftwards after loading the instrument you’ll see the problem. This shouldn’t happen. I suspect that an extra point is added as soon as you edit something.
Ha, between the 3 of us we’re bound to get this working at some point in the not distant future 
Yes, I think this happens here: LINK. I don’t understand why that code adds that 1.
I think it could be difficult to make it work without changing that function in the Cabbage code…
You hardly expect me to know? 
I think it might have something to do with extended guard points. That’s the only thing I can think off. It was probably a stopgap measure that somehow stayed around. Removing it fixes the problem, but we’d need to take a look at the GEN examples from Iain to make sure none of them are broken…
Well, as long as it’s not getftargs’ fault I’m fine with it! 