Cabbage Logo
Back to Cabbage Site

Velocity curve widget?

#39

You hardly expect me to know? :smile: 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ā€¦

#40

Well, as long as itā€™s not getftargsā€™ fault Iā€™m fine with it! :sunglasses:

#41

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)

#42

This works quite well. The prize is yours :wink: 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.

#43

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.

#44

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. :wink:

1 Like
#45

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ā€¦

#46

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?

#47

@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.

#48

@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.

#49

Regarding the line, you can change the thickness. Check the docs, I think itā€™s outlinethickness()

#50

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?

#51

@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. :upside_down:

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)

#52

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.

#53

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ā€¦

#54

Thatā€™s strange? The guirefresh() value sets the number of k-cycles between updates. It should never causes them to be skipped?

#55

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). :wink:

#56

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?

#57

Hopefully. I can replicate the problem here. Youā€™ll need to leave it with me. Iā€™m totally swamped at work these days.

#58

Thanks.
Could the problem be inside this function?