I recognize the funny/unintuitive behaviour of ctrlinit. I was going to write this email so suggest that you use the slider (e.g. slider8, slider16, etc.) opcodes instead, as they provide proper initialization of values. When testing slider, just to make sure my suggestion was indeed correct, I found that the precense of slider8 affects the initialization of ctrl7 as well. So a ctrl7 *with the same channel and ctlno* as used by a slider opcode, will be initialized by the slider opcode. Example below. Oeyvind ;******************************************** instr 1 ; ctrl opcode ctrlinit 1, 1, 2 kt ctrl7 1,1,0,3 printk2 kt, 10 ; slider opcode section, ; comment out fro here and until endin to disable slider opcode k1,k2,k3,k4,k5,k6,k7,k8\ slider8 1, \ 1, 0, 3, 2, 0,\ 2, 0, 3, 2, 0,\ 3, 0, 3, 2, 0,\ 4, 0, 3, 2, 0,\ 5, 0, 3, 2, 0,\ 6, 0, 3, 2, 0,\ 7, 0, 3, 2, 0,\ 8, 0, 3, 2, 0, printk2 k1, 30 endin ;******************************************** 2008/4/21, Art Hunkins : > Two further observations: > > 1) Ctrlinit (with ctrl7 expressing a range other than 0-127) must be placed > in instr 0 (i.e., the header) for it to work properly. (I don't understand > why otherwise, it keeps ctrl7's output to its initial value!) > > 2) The initial value for ctrl7 determined by ctrlinit works like this: > ctrlinit assumes the full range of 0-127. If ctrl7 has some other range, > ctrlinit maps its full range onto that of ctrl7. Thus, ctrlinit = 64 means a > value slightly more than halfway between ctrl7's min and max. Example: if > ctrlinit = 64 and ctrl7 min = 1 and max = 10, the initial output value for > ctrl7 (which applies until that controller is moved) is slightly more than > 5.5. > > So, if you want the minimum value, use ctrlinit = 0. If you want maximum, > use ctrlinit = 127. (0 = min, 127 = max; half the way between = half the way > between min and max.) And do it (ctrlinit) in the header. > > Art Hunkins > > ----- Original Message ----- From: "Art Hunkins" > To: > Sent: Sunday, April 20, 2008 7:14 PM > Subject: Ctrl7 initialization anomaly > > > > > I'd like to report some unexpected results when initilizing ctrl7. > > > > I've always used the full MIDI range (0-127) with ctrl7, and have always > initialized with ctrlinit to a value of zero. What I've just discovered, > though, is that intialization only works as you'd expect when ctrl7's range > is 0-127. (Even then, if you omit ctrlinit, ctrl7 initializes to *127* > instead of zero. Indeed, lacking ctrlinit, it always initializes to the > highest allowable value.) > > > > Where things get weird is when the range for ctrl7 is other than 0-127, > and you need to use ctrlinit in order to specify an initial value other than > the highest listed. (Now I know why I've always needed to *move* controllers > physically to zero after starting csound and before turning on the first > note - if controllers were being used as volume faders. It really would be > nice to be able to preset controllers to zero *before* starting csound. If > you forget to move the faders at the proper time, you'll be in for a rude > awakening - as in notes entering full force when they're started.) > > > > Basically, as shown in the .csd below, if you want the init value to be > the *lowest* specified by ctrl7 (as I'd think would be normal), you need to > set ctrlinit to *zero* instead of the lowest number of the range. Ctrlinit > seems to be assuming that ctrl7's range is 0-127, and if it isn't, is > adjusting/converting its calculations (in some way) accordingly. > > > > One other observation: substituting an init statement for ctrlinit - > either before or after ctrl7, has no effect whatever. It looks like the > running program reads a value from ctrl7 whether the control's been moved or > not - and overriding any simple init specification. (This would seem fine to > me if it defaulted to the *lowest value* of its specified range. > Unfortunately it doesn't.) > > > > I'd appreciate knowing whether all this works the same on other platforms. > You don't need a MIDI device for this, unless you want to see what moving > the controller (CC 7, the mod wheel) does to ctrl7's subsequent values. > > > > As long as you know what you're doing, you can work around this anomalous > behavior. It's just darned confusing. Probably would be a good thing to > document in the manual at least. > > > > Art Hunkins > > > > > > > > > > -odac0 -M0 > > > > > > > > > > instr 1 > > > > ctrlinit 1, 7, 0 > > k1 ctrl7 1, 7, 1, 10 > > printk 1, k1 > > > > endin > > > > > > > > > > > > i1 0 10 > > > > e > > > > > > > > > > > > Send bugs reports to this list. > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe > csound" >