Cabbage Logo
Back to Cabbage Site

Problems controlling parameters

#1

Hi all,
I have a csd file working fine on CsoundQt, but I am having problems creating its version for Cabbage.

  1. the range for vslider and hslider are not working properly: I am trying to initiate it with a starting value but it is not working;
  2. I am trying to control the knobs and sliders values with a Korg NanoKontrol with ctrl7 opcode, but everytime I try it Cabbage freezes and I have to force quit it. How do I control Cabbages parameters properly?
  3. The Mix parameter values are not working: no effect at all. It works fine on CsoundQt.
    I have attached the csd file version I am using on Cabbage and the original one I use on CsoundQt.
    What am I doing wrong?
    Thank you.
    (Mac-Mini Yosemite, i7quad, 16gb)

marua.csd (2.3 KB)

maruá_wah.csd (11.1 KB)

#2

Which version of cabbage do you use ?
Here is a little instrument which should work with a controller (check controller number first).I tested it … it works…

<Cabbage>
form caption("Untitled") size(400, 300), colour(58, 110, 182), pluginID("def1")
vslider bounds(70, 10, 75, 100) range(0, 1, 0.5,1, 0.1) channel("gain") text("Depth") valuetextbox(1) trackercolour("lime") outlinecolour(0, 0, 0, 50) textcolour("black")
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d --midi-key-cps=4 --midi-velocity-amp=5 ;--midi-key-cps=4
</CsOptions>'
<CsInstruments>
; Initialize the global variables. 
sr = 44100
ksmps = 32
nchnls = 2
0dbfs = 1
gkDepth init 1

instr GetCtrl
 kCtrler20 ctrl7 1,20,0, 127
    if changed(kCtrler20)== 1  then
	; Controller sends values between 0 and 127
	; bring the value between 0 and 1
      kDepth0 = kCtrler20 / 127.0
	; set the value of the slider  
      chnset kDepth0,"gain"
  endif 

  if changed:k(chnget:k("gain"))==1 then 
  ;get the value of the slider
	gkDepth = chnget:k("gain")
  endif
endin 


instr 1 ; controle midi
   
  /*  Note the --midi-   option in <CsOptions>
       Note that there are 2 variables, kDepth0 and kDepth, in order to avoid conflicts between reading and writing
      Not sure this is mandatory.
      Do what you wanna do with gkDepth  starting here   
      
      i.e. : modulate amplitude of VCO2
   */
   
   aOut vco2 p5*gkDepth,p4
  outs aOut, aOut
endin


</CsInstruments>
<CsScore>
;causes Csound to run for about 7000 years...
f0 z
;starts instrument 1 and runs it for a week
;i1 0 [60*60*24*7] ; not needed as midi message are sent to instr 1 by default.
i "GetCtrl" 0 z  ; listen to controlers
</CsScore>
</CsoundSynthesizer>
#3

Thank you very much. As soon as I get back home I will try it and send you my feedback.
Bests

#4

Hi again Karamel1, your code works fine, thank you.
I read it and understood almost everything, except what is the changed:k / chnget:k instance. What does those “:k” means? To which instance they are referring to?
Thank you again.

#5

If I not wong, this is to ensure that values are read at k rate.

#6

Yes, the “:k” part forces changed() opcode to check for changes in the variable at the k-rate. you could also do changed:i() or changed:a() if needed. These types of casts are a little confusing to at first, because they’re not documented well (at least that I’ve seen) and I think only some of the opcodes support them. But I’m sure there’s some reasoning to which support it and why somewhere…

That said, I’m a little confused by:

if changed:k(chnget:k("gain"))==1 then 
;get the value of the slider
gkDepth = chnget:k("gain")
endif

Since it’s assigning the variable when it changes, couldn’t you just assign the variable regardless of if it’s changed? Like so:

gkDepth = chnget:k("gain")

It might just be an artifact from other code that was there before, perhaps rescaling it etc… but just figured I’d point it out. :slight_smile:

#7

All opcodes should support rate specifiers. If you find one that doesn’t we should report it on the Csound list. You’re right about the documentation, I hadn’t noticed. wonder what the best part of the manual to add such information is? If you’ve any ideas let me know.

#8

In cabbage doc, there could be a chapter on “Good practices for coding” with Cabbage. It does not mean that things should be binding for programmers but, as far as Cabbage2 is moving forward with modular coding, being able to manage a lot of widgets, this could belong to such a chapter.
As far as it would be in Csound, I think Iain and Friends could write a paragraph in the FLOSS manual.

#9

I’m reluctant to suggest a coding style for Cabbage users, but perhaps a coding style guide for newbies would be Ok?

#10

yes, you can call it as you want.
The thing is there are a lot of tricks which are embedded within the instructionnal. It should be good if these were shown somewhere in the text of the manual.
For example, Loading file into soundfilers from a preset took us both a lot of efforts to succeed in a rational way. It could save a lot of time to others users if they were told in the manual :
" Better than doing this…, it is easier to do that way…"
Another example : it is not necessary to bring the GUI management within the audio instrument, this can be achieved differently, with separated instruments… but some precautions have to be taken…

So you see, it is not telling people how they must do, but rather to give them hints for easier code management. Because I am cabbage addicted ( I accept it :slight_smile: ) , I consider that cabbage has become a programming language as such even if it relies on Csound.

#11

You’re not wrong there! I guess we should include more examples in the docs for each widget.

But you can easily, and just as efficiently, put GUI code into an audio instrument. It’ really down to personal taste. I think the best way to encourage good coding practice is by publishing instruments that are easily read by beginners. But I will try to add more suggestions in the docs for various widgets. I think they could always do with more info.