Random CC patches

[noise2sine]

Hello,

I have made a simple patch grouping 8 Random CC subpatches in order to control different parameters of my analog synth. All of the 8 subpatches are routed to a unique midi out . My question is : is it a good way to proceed like that ? is there a "midi polyphony" ? do u think it's efficient ? Because when the 8 Random CC are playing at the same time i have noticed that there's some confusion between the settings i have made on my patch and the movement created on the knobs of my synth....


thank you!

[noise2sine]

up !!!:)

[23fx23]

have to investigate but from what I expreienced more than 3 cc in.or out at the same time seems to lead to confusion in my setup too, don't have solution.

[bsork]

I suppose you're sending these CCs out through a MIDI interface, in which you might overload one of the involved interfaces with too much data.

The MIDI specification is for 31.25 kbs IIRC, which you would have a hard time overloading manually creating the data, but with a computer that's no problem. Even if the interface buffers aren't overloaded or the MIDI bandwidth isn't exceeded, it might be too much data for the synth to handle. Does it work ok if you send less data? For instance by making sure that only one of the CCs is sent for each block?

[noise2sine]

Thanks for yr answers !!! As you said Bsork it's working ok when i'm using 2 CCs, with more the result is really messy!!! Do i have to set each patches to a different midi chanel ? because at the moment they are all set on channel 1? Do u have any idea about a different organisation ?

cheers

[amiga909]

u can even manually overload the midi bandwidth pretty easily:
- midi has a bandwidth of 31.25 kilobytes per second
- a 'lightweight' midi message such as CC has 3 bytes: status byte (msg type, channel), data1 byte (CC no), data2 byte (CC value)
-> 1000 messages per second are possible
- now: say u would move a fader (transmitting CC's) from 0 to max, 4 times a second. this generates 4*128=512 messages
- manually, with 2 hands: with 2 faders, u already may have problems.
- then look at a pitchbend wheel: pitchbend (with fine tune) counts as 2 CC messages, therefore only 500 values/second. without calculating this, i assume a single pitchbend movement can easily max out the midi bandwidth!

idea1: thin data after generating (eg. every 4th message is skipped).
idea2: tie the generation rate to the 1000 messages per second limit

[bsork]

Do i have to set each patches to a different midi chanel ?

I'm pretty sure that won't help, unless there's something very strange in the way your synth handles messages, eg putting each channel into it's buffer or something. Thinning data one way or another is most probably the way to go.

Another idea: Use for example a counter and selector to select only one of the messages per block, unless you're using a sample rate/block size that requires even more thinning. My impression is that most usiners use 44.100 kHz with a block size of 128 or 64. 44.100/64 gives 690 executions per second, so it's well within the MIDI bandwith, but as I've stated above, the synth might have trouble handling the data, especially f it's an old one.

[23fx23]

idea1: thin data after generating (eg. every 4th message is skipped).
idea2: tie the generation rate to the 1000 messages per second limit

good ideas gonna try, think it will work for output, not inputs. arf it's time they make a midi2 no?

[runagate]

idea1: thin data after generating (eg. every 4th message is skipped).
idea2: tie the generation rate to the 1000 messages per second limit

good ideas gonna try, think it will work for output, not inputs. arf it's time they make a midi2 no?

OSC was intended to be the replacement for midi. In 1993, wasn't it? It drives me crazy that VSTs are wedded to midi solely because the hardware companies refuse to see the value in a big changeover to OSC.

It might also be useful to "slew" your midi data since not all VSTs are going to be especially happy getting 1000 messages per second... what's the ppq of Usine? It's never occured to me before.

[amiga909]

comments above: yes, it depends a lot on the software implementation (and midi interfaces on computer and synth), i was only speaking about the hardware connection limits. in my experience the difference in responsiveness are vast among different devs.

dont know why it works better when u go over seperate midi outs. do you adress different physical midi outs?

OT:

OSC was intended to be the replacement for midi. In 1993, wasn't it? It drives me crazy that VSTs are wedded to midi solely because the hardware companies refuse to see the value in a big changeover to OSC

working with computers u could go over LAN of course.
many recent synths have a USB port so they could probably communicate via OSC in future.

the problem of OSC are truly the synth companies. MIDI has a large set of standardized messages (every synth shows same behavior for same message), which OSC has not yet.
the fact Dave Smith achieved to set up a non-propietary music communcation in the 1980s, involving roland, oberheim, yamaha and many others was an incredible effort.
i always like to defend MIDI cause its still suited for making music. limits also give possibilities to work more exact. do you really need more than 16x128 CC's? is a filter sweep automation with billions of steps better than with 128 steps? for me the only real failure of MIDI is that there a two messages (NoteOn, NoteOff) instead of one message for notes (on the other hand, this would have made MIDI more software dependant if you consider recording notes live).

[23fx23]

the actual exemple make me think midi is, even if I also have admiration for it, out of date:

from live I send 3 automations CC to usine, bandwith seems overload and I lost messages (3 automations is not a lot no?)
of course sending from usine i can slew the data, but to my knowledge no other "daw" can reduce midi data sent out sadly....
I thought using separate virtual midiports would solve the pb, seems it doesn't and windows must collapse them all to one only midi port, seems useless then..
or should I manually draw steped curves? seems a boring workaround, and maybe live would send each ppq, not changes...
. why don't they just increase bandwith, keeping midi protocol?

(yes I know i should let down live , soon but not yet)

[amiga909]

but to my knowledge no other "daw" can reduce midi data sent out sadly....

sonar has such a midi fx.
then, there are midi plugins that can do it. good for that job: midiCCstepper by inzertPizHere
http://www.thepiz.org/dl/?p=vst
Live might not be allow to insert a midi plugin after automation curves? dont know..

I thought using separate virtual midiports would solve the pb, seems it doesn't and windows must collapse them all to one only midi port, seems useless then..

for virtual midi ports there is no 1000 CC/sec issue (this only counts for the physical transmission over a midi cable). virtual midi ports are known to be sloppy - this is a software problem. u might try yoke, if u havent already.

[23fx23]

thanks amiga for stepper tip, gonna try.
didn't kew the limit was only for physicall cable, so limit is extended in full software..
i was on midiyoke on xp, doesn't work on w7 so tried loopbe, have to investigate but seems i got pbs even if spreading among several midiports, strange.. did you try/manage to get more than 3cc at same time in usine from another soft using yoke?