Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Issues with midi vst plugin

For general discussion related FlowStone

Issues with midi vst plugin

Postby n0n » Fri Apr 05, 2019 4:12 am

So I have created this VST instrument that transposes midi. It works flawlessly in Flowstone but when I try to use the plugin in my DAW it doesn't behave like it should. If I play my midi piano slow it mostly works, but if I play fast there are a lot of artifacts. I think I'm doing it right but I don't know. I would appreciate any insight. Thank you.
Attachments
Transpose Midi v3.fsm
Bit of weirdness
(37.64 KiB) Downloaded 751 times
n0n
 
Posts: 4
Joined: Fri Mar 15, 2019 4:50 am

Re: Issues with midi vst plugin

Postby Spogg » Tue Apr 09, 2019 11:53 am

I think this might need a Ruby expert to help.

However, I think the problem might be because you are going from MIDI to green, then Ruby, then green to MIDI. This green stuff may well be introducing timing errors.

Also, Ruby can process and output MIDI directly, so maybe try that...?

Cheers

Spogg
User avatar
Spogg
 
Posts: 3318
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: Issues with midi vst plugin

Postby trogluddite » Tue Apr 09, 2019 9:23 pm

I agree with Spogg, my first port of call would be to use Ruby's built in handling of MIDI events. As well as quite likely messing up the timing, splitting the Midi events externally is likely to lead to other problems. I haven't had time to completely analyse your code, but here are a few, I hope constructive, comments...

Firstly, despite what you might expect from the friendly "changed" trigger output, all of the integer outputs from the Midi splitters will be sending events to the Ruby primitive - each of the four in turn, followed by 'changed'. So, with both Midi inputs set to the same source (as saved), every incoming Midi event will be calling the Ruby 'event' method nine times! Because the inputs are updated one at a time, this also means that the Ruby 'event' method is being called when the integer data is 'unsafe' because it has only been partially updated (e.g. status of the current note changed, but channel, note, etc. are still from the previous one.)

The 'if i' branch of the event method (with no == value), will currently be called for all of these intermediate states (i.e. multiple times per Midi event), because only the discrete objects 'false' and 'nil' count as being a 'false' conditional in Ruby (the first argument to 'event' is a RubyEditConnector object, so is always counted as 'true', whatever its value.)

Handling each Midi event as a single Midi 'container' object will make this much easier to manage, as you'll always be presented with a 'whole' Midi event containing only valid data. There's no penalty for using Midi events as elements of a Ruby array, as all elements only store references to the object rather than copying it; so any buffering can be done directly with Midi objects.

After just a quick scan, I'm still a little uncertain how the buffers are operating. I can see why some buffering might be necessary in order to correctly handle changes to the transposition value while there are already notes playing. However, I get the impression that your buffers are partly a workaround for issues caused by the things I've noted above. I think this will probably become much clearer once the code is using Ruby Midi objects, as you shouldn't need to address the @ins array as much, and "@midi.channel" will be a lot easier to read than "@ins[1]" etc.! NB: You can assign new values to the Midi object properties as well as read them - though this isn't documented in the user guide (p.219 for the Ruby Midi stuff.)

One last thing. I'm not sure if having two separate Midi inputs is just to make testing easier, but as FlowStone currently only supports VST version 2.4, you can only have one Midi input to an exported VST plugin (one of the reasons I'd love to see an upgrade to VST 3+).

I hope that's helpful - feel free to fire back any questions if I've just made things more confusing! :D
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK

Re: Issues with midi vst plugin

Postby n0n » Fri Apr 12, 2019 6:06 am

trogluddite, you have described exactly what I've done. I am new to ruby and FlowStone and cannot find documentation of for a MIDI object... But then your hint @midi.channel made it clear what I have to do. I think I'm on the right path now. Thank you both for your insight.
n0n
 
Posts: 4
Joined: Fri Mar 15, 2019 4:50 am

Re: Issues with midi vst plugin

Postby trogluddite » Fri Apr 12, 2019 1:08 pm

You're welcome. I think that most of us here would admit that the documentation for FlowStone is a bit poor - especially the lack of working examples.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
User avatar
trogluddite
 
Posts: 1727
Joined: Fri Oct 22, 2010 12:46 am
Location: Yorkshire, UK


Return to General

Who is online

Users browsing this forum: No registered users and 37 guests

cron