VST LUA beta -- midi scripting VST

[mbncp]

Setting the outs to 0 and synth to 1, still does not enable midi outputs in Sonar.

It works here, maybe you need to rescan your VST folder.

Anyway, the bad news is that Sonar's vst-midi is a total disaster, the main problem being that all MIDI events loose their timestamp in the operation.
But as most users don't notice it, I guess it's ok.

[Dewdman42]

I will try to rescan.

So please comment further about losing their timestamp. That should not be the case for Sonar in general otherwise nearly all virtual synths in Sonar would have blatantly terrible timing that would get worse with large audio buffers.

???

[mbncp]

I will try to rescan.

So please comment further about losing their timestamp. That should not be the case for Sonar in general otherwise nearly all virtual synths in Sonar would have blatantly terrible timing that would get worse with large audio buffers.

???

It's not the same situation, as the midi is sent back to the input in this case. Then it behaves like live midi input, the delta is always 0.
You can check with this:

Code: Select all

function midiEventCb(midiEvent) 
 if midiEvent.type==midi.noteOn then
        vprint(midiEvent.delta.."  Note on "..numberToNote(midiEvent.byte2).." "..midiEvent.byte3.."\n")
    end
   sendMidi(midiEvent)
end

[Dewdman42]

I would if I could, but vstlua still not working for me here.

[mbncp]

I would if I could, but vstlua still not working for me here.

Try to re-start Sonar.
Btw which version do you have (7 here).
Can you check enable midi out now ?
Sometimes Sonar needs to play for the vst-midi to work.

[Dewdman42]

I got it working by removing the pluging from my vstplugins folder, startingand stopping sonar and then putting it back again. (shrug).

it works!

The timestamping issue is a curious one and we should try to get to the absolute bottom of it and then talk to cakewalk if there is something they need to change. But my understanding from recent conversations with Noel, is that the midi events are timestamped when coming into any vst snth for the vst synth to be able to figure out where in time they are supposed to land in the audio buffer. So they should be received by VSTLua with timestamps absolutely. I can't see why they would not, unless VSTLua is eating the timestamps in some way.

Also, I am not sure what is supposed to happen on midi OUTPUT, since there is no rendering to an audio buffer, presumably the midi output must also be timestamped in someway that can be passed on down the midi pipeline, but its an interesting question....is Sonar the one eating that timestamp or is VSTLua?

[mbncp]

The problem is with Sonar. The reason is that there is no proper midi routing like in vsthost or ext when sending midi from plug to plug.
Sonar will put the output of a vst midi in the input queue. As it can't deal with it within the same buffer call, it will try to deliver the midi as fast as possible in the next buffer, thus setting the timestamp to 0.
So the next plug in the line receives the event from 1 sample to a full buffer late.
Example, using my vstspy plug, these events should play at the same time, but the one that makes it thru the plug is late.
current time in msec, buffer call, timestamp, midi data

Code: Select all

9237593	35197	0368	90	048	108
9237609	35198	0000	90	048	108

As we see the second event is about 16 msec late (not pure science), is not in the same buffer call and the time stamp is 0.

So as my buffer in this case is 1024 samples, the events is delayed by 1024-368 = 656 samples in this case, but could be anything between 1-1023 samples.

[Dewdman42]

Yet something else to complain about Sonar's crappy midi plugin handling.

This situation I guess does not exist for MFX plugins presumably because they are inline in the midi track handling...as opposed to the way we have to use VST midi plugins where the midi output has to appear as a "midi port"...which like you said...just queues up the event as if someone is playing it.

Still, that doesn't explain to me why the midi event coming into VSTLua would have a 0 timestamp. Your explanation does explain why the midi OUTPUT would eat anytimestamps though.

[mbncp]

>>Still, that doesn't explain to me why the midi event coming into VSTLua would have a 0 timestamp

Sorry I didn't make that clear, but it doesn't in the first instance, only in the second one or when playing live in the first one.

Track -> plug is ok
Track -> plug -> plug is bad timing

>>This situation I guess does not exist for MFX plugins presumably because they are inline in the midi track handling...

There are also a couple of problems with mfx, but it's globaly better and doestn't have THAT timing issue.

[mbncp]

Btw, in Sonar, if you chain vst-midi plugs, after each plug the events are delayed by 1 buffer.

Great for a strumming fx, just change the asio buffer size to have a different strumming interval

[Dewdman42]

basically, this means that any kind of midi operation that is timing sensitive, then Sonar is currently not equipped to handle VST midi plugins. Period. The plugins like chordspace, etc...are more like experimentation things...but if you depend on the note timing being accurate, than Sonar is NOT equipped properly to handle VST midi plugins. pure and simple end of story. Let's hope they fix it.

In the meantime, this may be a use case for someone like Markleford to figure out how to build this thing as an MFX, though that might be easier said then done.

[mbncp]

>> In the meantime, this may be a use case for someone like Markleford to figure out how to build this thing as an MFX, though that might be easier said then done.

Mfx with Sonar is a bit a pain. Track note events have always a duration and it's not possible to split it into a note on, note off event due to yet another Sonar bug.
Another problem is that there is no good timing with live events, I think the timing resolution is 60 or 80 msec.
It should still be possible to do something but the difference of the two systems would require a couple of changes, making most scripts incompatible.

[Markleford]

Yes, MFX has some 'quirks' (esp with the two separate message pumps), and you unfortunately can't change that timing resolution. We keep hoping that SONAR does something to "reinvigorate" this, whether it be by fixing the MFX shortcomings, or my fully committing to VST MIDI!

(Still, that's not to say there's not LOTS you can do with MFX: it's just that the API and support haven't changed since not long after it was introduced in Cakewalk Pro Audio 8 or so!)

- m

[contrast]

Went from .03 to .05 yesterday, the stability in general is much improved. But, it seems to hang the DAW (SX3) on reset or close if I have opened any sockets. I am closing them in resetcb (tried also just not closing them to see if closing them was what was hanging it, but it still happened).

There is no error message, the DAW and Vstlua just become unresponsive.

[tzec]

Went from .03 to .05 yesterday, the stability in general is much improved. But, it seems to hang the DAW (SX3) on reset or close if I have opened any sockets. I am closing them in resetcb (tried also just not closing them to see if closing them was what was hanging it, but it still happened).

There is no error message, the DAW and Vstlua just become unresponsive.

OK, sockets are definitely screwed, I get the same problem on all the hosts I tried. I'll look into it.

Contrast: does this happen with sending, or only with receiving? I only have receiving problems here.