posted 18 January 2002 03:22            

I am trying to sync KYMA up to an Electrix Repeater, and besides a number of MIDI beat clock oddities, I cannot get KYMA to start/stop analog sequencers in response to the repeater.

The repeater is a little odd (I think) and sends a MIDI cc 85 ( value 127?) message when it starts, and a CC 87 message when it stops.

I can't figure out how to convert those to different messages into a start/stop controller. If it were 2 different vaules of the same CC, I'd be in business, but I don't think the repeater is varying the CC values, just resending 127, or something.

Hw can I have a parameter such as an analog sequencer gate, retrigger every time KYMA recieves a message !cc85 even if it's the same value?

The closest I got, was using !cc85 asToggle, but for somereason, it toggles EVERY OTHER time it recieves a start message from the repeater.

???

Anyway, even if that weren't wierdly true, I had to go a number of steps removed to make the !cc85 trigger and/or retrigger, and the !cc87 stop

by converting !cc85 into a controller called !start,
then taking !start (for some reason I need a new globalController to do this)

(((!Start asLogicValue) fullRamp: 0.001 s) + ((1 - !Start asLogicValue) fullRamp: 0.001 s)) ramp: 0.1 s

and that outputs !RealStart

then I do the same thing with !cc87 and output !stop which outputs !realstop

then I combined them into !StartStop with:

!RealStart - ((!RealStop lt: 0.5 asLogicValue) sustainBy: (!RealStart gt: 0.5))

so because of all the ramp, the !start can be used to retrigger, but the !stop stops playback, but I can't get any of it to work anyway because the toggle only toggles half the time in the first place.

any thoughts?

posted 19 January 2002 17:28            

I'm not sure that would work, 'cause the problem is that the cc value doesn't change, it's always 127.

But besides that, I've never gotten that expression to work. Can anybody help me out with that?

The .pdf sez it's called hasChangedReset, and the example only uses hasChanged: is that a misprint or is that correct?

posted 21 January 2002 08:08            

Set-up: I configured a box to send MIDI CC 85 and CC 87. When I pressed button A, the box sends MIDI CC 85 with value 64. When button A is release, the box sends MIDI CC 85 with value 0. Button B behaves similarly using CC 87.

Next, I have a SoundToGlobalController with
Value: (!cc85 gt: 0.5) hasChangedReset: (!cc87 gt: 0.5)
GeneratedEvent: !Run

So when I press button A, !Run becomes true. It remains true regardless of further MIDI CC 85 messages until I press button B.

I'm not sure if this does what you need but at least it explains the hasChangedReset: message.

BTW: You can access the "true" spelling of message via the shift-control-H shortcut when the cursor is in a hot parameter field. The shortcut displays a drop-down list containing all legal real-time operators.

posted 22 January 2002 13:47            

Thank for the explanation of hasChangedReset, that was informative.

The problem is that unlike your test scenario, the Repeater only send 1 value (127) for each CC#. So it send cc85 127 for start and cc87 127 for stop and never sends anything else.

Making it really difficult to convince Kyma to treat these messages as new information.

posted 23 January 2002 06:32            

Of cause you can't emulate the problem with two push buttons on a VCS because the buttons send out 1 values when pushed and (more importantly) 0 values when released.

What kyma would need to have is a message/nomessage detector. I think there is some low level code in kyma that gives access to the raw midi messages but I don't know what it is.

posted 23 January 2002 08:55            

If that is so, then you should try to build a "mono-stable" type structure. i.e. - one that resets itself after a short period of time. I haven't tried this, but I imagine that such behavior could be attained with delay and feedback.

Where's the guy that posted those logic gates a while back? He might have an idea about this.

-oh, now I see what you mean. Kyma continues to use the last value it received when it is evaluating the expression.

You'll need a self-resetting structure...

posted 23 January 2002 10:03            

The controller is sending out both stop and start messages, but they are telling kyma to set the cc values to the same values that they already are already set to. Hence nothing happeneds and this is just as if you pulled the midi lead out compleatly.
It doesn't matter how may monostables or logic gates you add if the inputs don't change you don't get anything sensible out.

The only way to make it work is to 1)fit return springs on the rocker switches or 2) use non latching push buttons instead.

The first could be done buy merging another machine into the midi stream that keeps sending out 0 values on the same controler types that stop and start use (not realistic)

The second could be done by not using the kymas !ccXX mechanisum which latches the input values, but instead get to the raw midi data.

posted 23 January 2002 12:49            

I actually made it so the cc87 (stop) resets the cc85, but then the cc87 gets pinned, and if you try to make the cc85 reset the cc87 as well ... you get a recursive loop and nothing works at all.

What's so completely odd is that if I set kyma to

!cc85 asToggle .... the value does switch from 0 to 1, but only every other time it recieves the cc85 127. So I press PLAY on the repeater, the output goes to 1, I press Play again, nothing, I press Play again, the output goes to 0, etc ... Same thing with STOP (cc87)

Isn't that just odd?

posted 23 January 2002 15:42            

I like your "rocker switch" analogy, Pete. And I agree that Kyma is doing the right thing. The Repeater's CC85 and CC87 commands are ambiguous.

The real-time expression evaluator won't re-evaluate:
(!cc85 gt: 0.5) hasChangedReset: (!cc87 gt: 0.5)
until either !cc85 or !cc87 change value. And they won't after the first MIDI message.

So it seems that you'd need some low-level Kyma code to recognize the raw MIDI. At least if you to control Kyma directly with the Repeater.

An expedient solution (spelled w-o-r-k-a-r-o-u-n-d) might be to use a product like MIDI-OX to remap the CC's to a NoteOn/Off sequence.

posted 23 January 2002 18:00            

Or using Bill Ms monostable idea with negative feedback.

posted 24 January 2002 02:43            

so I taked to Kurt and he came up with this:

If I multiply the cc85 by !Random I get a new random # every time.

So that's a pretty cool workaround, or so I thought.

But I guess I don't understand hasChangedReset:

I thought It would ouput a 1 every time the input changed, and then that 1 would be reset to 0 if the argument became greater than 1.

But it seems hasChanged refers only to a logical value ??

so I can't do !StartRandom hasChangedReset !Stop, because !StartRandom changing values doesn't seem to cause it to output 1.

Also it goes back to 1 again if the argument goes back to zero.

so if I do (!fader gt:0.5) hasChangedReset: !Keydown

once !fader goes past 0.5, !start goes to 1, and if I press a MIDI Key, !start goes to 0, but if I release the key, !start goes back to 1.

Hmmm.

posted 24 January 2002 05:30            

Your right that "has~ChangedReset" it is purely a logic thing and changeing any argument from say 0.2 to 0.3 has no effect at all, unlike the name seems to imply. I think that maybe ssc choose not to call it "SRFlipFlop" as they may have thought that non programers wouldn't know what it means. I'm just guesing here of cause.

So this means that you will need a two signals that always rest at zero but go positive whenever a change happends.

It could be done first starting with kerts "cc85 * !random"and then putting this through a one sample delay. Then by subtracting the non deleyed from the delayed you will get a streem of zeros with random non zero values only when a change happends. If you then find the absolute value of that , the all the random pulses will be forced to positive.
This would feed the left argument of the "hasChangedReset:" formular. I don't think you need the "gt:0.5" bit as its non zero values that we are interested in.
Now you do the same thing with the cc87 and put this into the right argument of the "hasChangedReset:" formular.

This might just work captin.

But it might need the delays to be set to (current sampler rate/1khz) samples, instead of one sample. This is because the "hasChangedReset:" formular works at 1 khz intervals and might miss the non zero spikes. This is not the sintax you would use but it tells you how to calculate how many samples delay to set the delays to.

posted 24 January 2002 07:31            

And by the way, the reason you was'nt seeing the "hasChangedReset" latching action in your first experiments, was because the argument that you're not changeing has to be at zero value for you to see a latch happen to the argument you are changing.

posted 24 January 2002 12:38            

That completely works.

Thanks so much.