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?
Statistics: Posted by 23fx23 — 19 May 2009, 10:47
]]>
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..
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.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..
Statistics: Posted by amiga909 — 19 May 2009, 10:36
]]>
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)Statistics: Posted by 23fx23 — 18 May 2009, 21:03
]]>
dont know why it works better when u go over seperate midi outs. do you adress different physical midi outs?
OT:
working with computers u could go over LAN of course.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
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).
Statistics: Posted by amiga909 — 18 May 2009, 11:59
]]>
good ideas gonna try, think it will work for output, not inputs. arf it's time they make a midi2 no?idea1: thin data after generating (eg. every 4th message is skipped).
idea2: tie the generation rate to the 1000 messages per second limit
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.
Statistics: Posted by runagate — 16 May 2009, 16:27
]]>
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?idea2: tie the generation rate to the 1000 messages per second limit
Statistics: Posted by 23fx23 — 16 May 2009, 13:44
]]>
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.
Statistics: Posted by bsork — 16 May 2009, 09:10
]]>
- 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
Statistics: Posted by amiga909 — 15 May 2009, 13:59
]]>
cheers
Statistics: Posted by noise2sine — 15 May 2009, 10:24
]]>
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?
Statistics: Posted by bsork — 14 May 2009, 13:57
]]>
]]>
]]>
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!
Statistics: Posted by noise2sine — 12 May 2009, 10:52
]]>