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ā¦
Velocity curve widget?
Well, as long as itās not getftargsā fault Iām fine with it!
We could avoid to change the actual behavior of the gentable if we could have a channel(āchanā) identifier that returns a value of 1 if the user interacted with the widget after the last widget reinit (first start or after a āf ā¦ā score event). In this way, in the Csound program, we could know if the user interacted with the widget and, based on this info, change the numbers of points to read.
EDIT: I attached my actual code. It loads the preset at start and as you change the preset in the combobox. If the file doesnāt exist, it creates a new one with a default 0ā1 linear velocity.
velCurve.csd (6.7 KB)
This works quite well. The prize is yours The
channel()
solution would work fine, but I think Iād rather look into removing that code first. I will do some tests and see how it affects other things.
Ok, keep in mind that when you change something in the widget, the number of (wrongly?) added points is 2, not 1. In the Cabbage code you do this:
if (table->genRoutine != 2)
{
fStatement.add (String (1));
fStatement.add (String (evt.p[pCnt]));
}
So you add a ā1ā followed by the value in āevt.p[pCnt]ā and those are the 2 added points that make trouble for us.
I just made a csd that works without having to change Cabbage source code for gentable widget.
works.csd (8.1 KB)
P.S.: thanks to Rory Walsh and Guillermo Senna for their support.
I wonder why there is some noticeable lag (at least on Windows) in the update of the curve when you change the presetā¦
EDIT: itās like a random lag⦠Sometimes is fast in changing the curve⦠Some other times you see about 0.2-0.5 seconds of lag. Itās not really an issue, but I wonder why there is this lagā¦
Very nice! And with minimum modifications it even works with my cabbage-bezier build.
The lag youāre seeing could be because of the large ksmps value you chose?
@gsenna, is that build using Cabbage 2? If so, can you make a pull request? Btw, I never had any luck deploying from TravisCI to bintray. Iām probably just missing a few simple things. I must try again soon.
@gsenna, those bezier curves are very beautiful! And I like that the curve has a bold line.
You changed the Cabbage code to make that?
[quote=āgsenna, post:46, topic:1203ā]
The lag youāre seeing could be because of the large ksmps value you chose?
[/quote]Yes, decreasing the ksmps reduce the lags a lot, but I donāt understand⦠A ksmps of 256 means parsing the Csound code every 0.0058 seconds (5.8 milliseconds)⦠I perceive a lag of about 0.2 seconds.
Regarding the line, you can change the thickness. Check the docs, I think itās outlinethickness()
Nice, but itās not good as in the @gsenna picture:
I think the problem is that the line has the same color of the table color, alpha included, so when the line is superimposed on the table fill, the transparency generates that strange effect. Can we change the color and the alpha value of the line independently from the table fill color?
@rorywalsh, unfortunately that image is just from using the Cabbage1 version I built in 2016. I should try to update the code to Cabbage2, but Iām still dealing with the same issues in my hands. I canāt promise anything, but hopefully next year Iāll be able to do it.
Regarding my other half-completed project, this is the gist of how I upload to bintray. Maybe you are missing the token?
for file in *; do
echo "Uploading assets... "
curl -s -T ${file} -ugsenna:${BINTRAY_TOKEN} "https://api.bintray.com/content/gsenna/installer-framework/installer-framework/1/travis_linux/${file}?override=1&publish=1"
done
@mauro, [quote=āmauro, post:48, topic:1203ā]
Yes, decreasing the ksmps reduce the lags a lot, but I donāt understand⦠A ksmps of 256 means parsing the Csound code every 0.0058 seconds (5.8 milliseconds)⦠I perceive a lag of about 0.2 seconds.
[/quote]
I thought the same, but after seeing the problem disappear by lowering the ksmps my guess is that fiopen and ficlose could be the culprits (?)
I donāt remember changing the code for that. These are my attributes:
gentable bounds(12, 66, 147, 99), tablenumbers(1111), tablecolour("red"), tablebackgroundcolour("white"), tablegridcolour(230,230,230), identchannel("table1"), amprange(0,1,1), zoom(-1), active(1)
Thanks @gsenna, Iāll try those commands. Looks pretty simple, but I think I might have set up bintray incorrectly to begin with. I do want to get it going because I think your Csound installer is really such an important step forward to Csound.
@mauro, it looks like you canāt currently set the colour of the outline. I honestly thought one could. Iāll fix that.
I just found that there is a Cabbage option (an option of the āFormā widget) to set the rate at which Cabbage will update its GUI widgets: guirefresh(val). If I set a val of 32, the lag will be very much reduced. However, there are some rare times when you change the preset that it doesnāt update the GUI at allā¦
Thatās strange? The guirefresh() value sets the number of k-cycles between updates. It should never causes them to be skipped?
Maybe that with a ksmps=256 and a guirefresh=32 sometimes the
scoreline_i Sscoreline
chnset "tablenumber(1111)", "table1"
statements send the message to Cabbage before the related ftable is changed (I think the ftable is changed by Csound in the next k-cycle). Iām trying some changes to run the same chnset statement in the following k-cycle too, to see if that could be the problem.
Anyway this is not a big issue, so I think itās not necessary to lose our heads on this⦠I think itās better a less demanding GUI with a little lag in loading the velocity preset curve, instead of a super-responsive interface but with some impact on the CPU (and, consequently, on the amount of notes you can play in polyphony).
Hi, Iām having some troubles with the nodes of the velocity curve graph⦠When I move a node near the extreme right of the gentable widget, the node immediately snaps to the right margin. This is a problem, because I cannot draw a steep velocity curve on the far right of the widget.
I noticed the same thing happens when you approach a node from the left, but strangely, it doesnāt happen if you approach a node from the right. So, there is a magnetic behaviour from the left to the right, but there is not from the right to the left. There is some way to completely avoid this āmagneticā behavior?
Hopefully. I can replicate the problem here. Youāll need to leave it with me. Iām totally swamped at work these days.
Thanks.
Could the problem be inside this function?