Cabbage Logo
Back to Cabbage Site

Velocity curve widget?

#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;
...
#61

Nice find. So you want to make a pull request? I can add your changes in the next few days but a PR would be quicker. And I’m also happy to have PRs coming in. It sets up a quicker workflow for resolving things. And thanks again for taking the time to look into this. I very much appreciate it .

#62

Ok, it’s my first time making a pull request, so I hope I have done everything right. :blush:

#63

I noticed that something was wrong in the velocity values returned by my $VELCURVE macro. For example, in the keyboard widget, when you press a note key with the mouse in the middle of it, you don’t get a 0.5 value, even when you draw a perfectly linear curve 0-1 in the gentable widget. But the problem was not in the macro… The problem was in this csound flag:

–midi-velocity-amp=5

It converts the velocity values [0, 127] it receives from midi note-on events to [0, 0dbfs] amp values (0dbfs is the global csound variable). Usually 0dbfs=1, but the conversion from [0, 127] --> [0, 1] is not linear, because amp values are in decibel… So, for example, a velocity value of 64 doesn’t translate in 0.5, but in 0.2. This is a problem because the $VELCURVE macro expects linear velocity values, not decibel, so the curve you draw in the graph doesn’t correspond to the requested velocity.

I solved the problem by using the following flag instead of the above one:

–midi-velocity=5

that simply returns the original MIDI velocity values without alterations. Being that they are defined in [0, 127], you have to make other little mods to the code:

...    
#define VELCURVE(vel) #
        $vel    tab_i   floor((giVelCurveRes - 1) * $vel), giFT_velCurve
#
...
instr 1
        iFreq	    =	        p4
        iAmp	    =           p5 / 127 ; <-- convert the MIDI velocity to [0, 1] values.
...

Now the curve will reflect exactly your desired velocity response behavior.

1 Like
#64

In the gentable widget, you could drag the first and last handle too and this led to an inconsistent and wrong behavior like the following:

I fixed the code so that you cannot x-drag the first and the last handle inside the graph on the x-axis, but only on the y-axis. And there is another problem with the fontcolour in the titlebar too: if you have a transparent fontcolour, when the window looses focus the hidden title reappears… I fixed this too. I will do a PR soon.

EDIT: sent PR. :wink:

#65

Nice one. Thanks for spending some time on the gentable widget. I’ve always felt it was jut a little below production ready. Your changes are a big help.