Cabbage Logo
Back to Cabbage Site

Velocity curve widget?

#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?

#59

It’s definitely in that file somewhere. I’m sorry I can’t be more assistance, but I’d need to run it through the debugger myself to pin point exactly where the issue is. And I probably won’t get a chance to do so until later in the week.

#60

I found the problem and fixed.

In the line 1766, if you get rid of that “getWidth()”, there will no longer be the magnetic behavior:

1766            else if (xPos /*+ getWidth()*/ > nextX)
1767                xPos = nextX + 1;
...