Midi & VST & VSTParameters

[matti]

Here's the thing..
When ever i create a VST that handles Midi, it sucks up huge amounts of cpu time. Wether it's a VSTi that sends midi over TCP or a VSTi that sends VSTParameter automation as Midi CC. The handling of midi(originating from the host) always hangs the audio thread and makes it wait for it's completion. This in turn means that turning a knob that send Midi CC will use up to 5% of available cpu time on a 3Ghz quadcore machine. More than 64 voices of Synth1

And it's not stable either. It usually corrupts the audio output with crackles. It seems the Midi thread is connected to the audio thread. This has been the way Midi works since the first versions of SynthMaker. Please fix it.

[matti]

Antoher bug concerning Midi:

https://dl.dropbox.com/u/880206/midi_bug.png
As you can see from the picture, the data is in the correct format, but it won't output as a midi event. Not even if you make it with the "Midi.new".

[trogluddite]

As you can see from the picture, the data is in the correct format

I wouldn't class that one as a bug - it's a simple a mismatch of data types, and is just the way that Ruby works normally...
The string that you're sending, and the code visible in the 'watch' window, isn't actually a MIDI message - rather it's the object's "label" - a string showing the class and Ruby ID number of the MIDI object. The hex number that you see in the string is not the MIDI data, just a code number for that particular MIDI object. The schematic will work fine if you change the connectors to be red Midi ones, or to a 'V' Ruby value type - you would then be sending the Midi object itself rather than the object's "label".
This is true for many classes of object in Ruby - when you use 'watch' or send to a string output, Ruby calls the '.to_s' or '.inspect' method for the appropriate object class, to get the objects string representation. What you get returned in the string depends on the definition of those methods. For objects that are useful for putting up on the GUI (e.g. numbers etc.), you'll get a nicely formatted string - but for many more complex objects it is just a class name and object ID, only really intended for de-bugging purposes by letting you know that you've got the object that you expected.
For Midi objects, returning a label seems sensible. When you ask for the string, it's pretty ambiguous what you are asking for - decimal values?, hex values?, a verbal description ("Note On A#3")? So it has been left up to the user to define their own "formatting" routine if anything more than a simple ID is wanted.

[matti]

As you can see from the picture, the data is in the correct format

I wouldn't class that one as a bug - it's a simple a mismatch of data types, and is just the way that Ruby works normally...
The string that you're sending, and the code visible in the 'watch' window, isn't actually a MIDI message - rather it's the object's "label" - a string showing the class and Ruby ID number of the MIDI object....

Good guess.. but no. You are wrong.
The text that gets passed is the four values that a midi message includes. It's just in it's raw hex form. It does the exact same thing(nothing) if i change the values to a table like shown in the FS manual and then create a midi event from that data with the call to Midi.new. The point is that you can't create a Midi event from Midi data, or table data. I guess it would work if i'd read the values independently and created the Midi event then. But as it stands, there's no use for this when VST-audio is interlocked with the Midi thread and robs all cpu time when used.. so i haven't bothered working around this.

I'd love to see these issues fixed. Would make my plugs work a lot better.

[trogluddite]

Good guess.. but no. You are wrong.
The text that gets passed is the four values that a midi message includes it in its hex form

No guesswork, I promise

It aint MIDI.fsm

(528 Bytes) Downloaded 1064 times

This shows the true MIDI hex and string together for comparison, and there is no correlation between them - if you send the exact same MIDI message twice, you'll see that the ID code in the string is different every time, as each event receives a unique ID number.
There's also a clue in your screenshot - all MIDI messages begin with a value >=7F, and the message body only has values <7F, so the string in the image cannot be a valid MIDI message.

Since you can pass the MIDI as a Ruby value, why convert to string and back again? - Ruby and 'green' are on different CPU threads, so converting Ruby <> 'Green' can mess with the timing (yeah, I know - green triggers are still just as unreliable as they always were!).

[matti]

No guesswork, I promise

It aint MIDI.fsm

This shows the true MIDI hex and string together for comparison, and there is no correlation between them - if you send the exact same MIDI message twice, you'll see that the ID code in the string is different every time, as each event receives a unique ID number.
There's also a clue in your screenshot - all MIDI messages begin with a value >=7F, and the message body only has values <7F, so the string in the image cannot be a valid MIDI message.

Since you can pass the MIDI as a Ruby value, why convert to string and back again? - Ruby and 'green' are on different CPU threads, so converting Ruby <> 'Green' can mess with the timing (yeah, I know - green triggers are still just as unreliable as they always were!).

Fair enough. It seems to be like you say. The point was to make it go over a network, so it needs to be in green. Or can you send it directly with Ruby?

Anyhow the same problem remains. Too much cpu usage for simple midi commands.

[trogluddite]

The point was to make it go over a network, so it needs to be in green. Or can you send it directly with Ruby?

Sadly, not at the moment - you'd have to translate to a custom string format somewhere in the Ruby, use the Green network prim's, and convert back again at the other end. Even the Ruby binary data packing methods won't do the job, because they can produce non-printing characters in their string output that green string connectors won't pass through.
Would be much better if we could to handle the networking from Ruby; because if, as you suspect, the CPU load is due to threading issues, doing Green<>Ruby conversions might only compound the problem - and introduce extra latency too.

[matti]

The point was to make it go over a network, so it needs to be in green. Or can you send it directly with Ruby?

Sadly, not at the moment - you'd have to translate to a custom string format somewhere in the Ruby, use the Green network prim's, and convert back again at the other end. Even the Ruby binary data packing methods won't do the job, because they can produce non-printing characters in their string output that green string connectors won't pass through.
Would be much better if we could to handle the networking from Ruby; because if, as you suspect, the CPU load is due to threading issues, doing Green<>Ruby conversions might only compound the problem - and introduce extra latency too.

You can do ipmidi with FS, no prob. I even have a working prototype and there's no problems with it, except for the exceptional cpu usage. Going Ruby was just another test on the subject. Ruby is after all a lot faster on some things.

Btw. I did some obvious mistakes on the pic there with Ruby. Bad day perhaps? Guess i might have been venting because i've been so frustrated with the datatypes of Ruby. Or the lack of. It sure is elegant to be able to code with no regard to datatypes, and the language just bows and accepts everything. But it starts to majorly piss you off when you try to convert a Sysex message string first into Hex, then Binary, after which back to Hex, then Integer, then Hex again, and back to String to send it to Midi. Cos that's exactly what i needed to do few days ago It was like eating nails, with some extra heavy wasabi on the side.

[matti]

Any comment from the developers on the issue with Midi's connection to the main audio-thread that causes huge cpu usage?

If it could be possible to do a Midi input(or stream) that is intended for "outside of audio-thread" processing. Cos i understand that currently it is made to be inside it to make host-midi automation to work properly on softsynth exports etc. I'd just need an alternative to this. I guess this is a similar request as the "host playback position" thing that eventually got done in "green" too (or was it the other way..anyhow). The stream only needs to be 31,250 bits per second as per Midi 1.0 standard.

[support]

Do you have a schematic you can email to us that shows the high cpu load you're experiencing?

If you could send us something that would be great.

Many thanks!