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
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
FS ability to call .dll's question
14 posts
• Page 1 of 2 • 1, 2
FS ability to call .dll's question
This will show how new I am to all this
Here B the question[s] ...
The basis stems from this idea.
Is it possible to load a separate .dll file INTO a FS project ??
Here's the wonder part ... I'm trying to see if a '3rd party' VST plugin can be 'housed' within a FS application?
This sound kinda crazy, but the intent is to provide a single control interface to a series of plugins.
Of course, in application, the VST .dll would need to be available on ones' system. My FS plug would provide MIDI communication to the housed plugins.
I'm trying to address a plug that has limited MIDI capability. I'm also finding that the various DAW's out there have certain ways they can only work, or that routing the controlling MIDI stream becomes a complicated issue.
If there was a way to 'contain' a set of plugs 'internally', this 'controller' would also serve as a 'Shell' [if that makes any sense.
Anyway ... not having a full understanding makes it difficult to even frame the right questions.
Maybe someone can offer some insight or possibilities.
Thanks very much !
Here B the question[s] ...
The basis stems from this idea.
Is it possible to load a separate .dll file INTO a FS project ??
Here's the wonder part ... I'm trying to see if a '3rd party' VST plugin can be 'housed' within a FS application?
This sound kinda crazy, but the intent is to provide a single control interface to a series of plugins.
Of course, in application, the VST .dll would need to be available on ones' system. My FS plug would provide MIDI communication to the housed plugins.
I'm trying to address a plug that has limited MIDI capability. I'm also finding that the various DAW's out there have certain ways they can only work, or that routing the controlling MIDI stream becomes a complicated issue.
If there was a way to 'contain' a set of plugs 'internally', this 'controller' would also serve as a 'Shell' [if that makes any sense.
Anyway ... not having a full understanding makes it difficult to even frame the right questions.
Maybe someone can offer some insight or possibilities.
Thanks very much !
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: FS ability to call .dll's question
Hi RJ,
Much as I hate to say it, you may be better off using SynthEdit for doing that - it has had plugin hosting for a long time, with a simple interface to the hosted plugin's VST parameters. (NB - I haven't used SE for many years, this could have changed!)
Allowing SM/FS to be a host has been requested before. Whether there are technical reasons why it hasn't been done, I'm not sure, but the dev's reluctance could equally be ethical/legal - not wanting to open up the software to a horde of unscrupulous users who might try to 'wrap' commercial plugins to make a fast buck!
Ruby does now have the ability to talk to .dlls - they are really nothing more than a bunch of code functions that you can pass parameters to and get answers back - not so different to Ruby's 'methods'. So with much study of the VST spec's it should be possible to pass audio buffers in and out of a plugin, and manipulate its parameters.
However there are a couple of reasons why you probably wouldn't want to do it this way...
- Speed. Ruby isn't too sluggish for an interpreted language, but it isn't really up to "real-time" audio crunching. Passing audio buffers in real-time would really tax your CPU - we can see this with the new "frame" components; they are nice to have when there is simply no other way, but "Ruby DSP" sure gets that CPU meter rising fast! This kind of real-time interfacing really needs super-fast, low CPU, compiled code.
- Graphics. FS has just one big Window that we 'paint' our graphics onto, whereas a plugin would expect to be handed a nice little "independent" space on screen in which to do its own drawing. At the moment, we don't have the kind of control over windows that this would need - likewise for mouse/keyboard handling.
Much as I hate to say it, you may be better off using SynthEdit for doing that - it has had plugin hosting for a long time, with a simple interface to the hosted plugin's VST parameters. (NB - I haven't used SE for many years, this could have changed!)
Allowing SM/FS to be a host has been requested before. Whether there are technical reasons why it hasn't been done, I'm not sure, but the dev's reluctance could equally be ethical/legal - not wanting to open up the software to a horde of unscrupulous users who might try to 'wrap' commercial plugins to make a fast buck!
Ruby does now have the ability to talk to .dlls - they are really nothing more than a bunch of code functions that you can pass parameters to and get answers back - not so different to Ruby's 'methods'. So with much study of the VST spec's it should be possible to pass audio buffers in and out of a plugin, and manipulate its parameters.
However there are a couple of reasons why you probably wouldn't want to do it this way...
- Speed. Ruby isn't too sluggish for an interpreted language, but it isn't really up to "real-time" audio crunching. Passing audio buffers in real-time would really tax your CPU - we can see this with the new "frame" components; they are nice to have when there is simply no other way, but "Ruby DSP" sure gets that CPU meter rising fast! This kind of real-time interfacing really needs super-fast, low CPU, compiled code.
- Graphics. FS has just one big Window that we 'paint' our graphics onto, whereas a plugin would expect to be handed a nice little "independent" space on screen in which to do its own drawing. At the moment, we don't have the kind of control over windows that this would need - likewise for mouse/keyboard handling.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
Don't stagnate, mutate to create!
-
trogluddite - Posts: 1730
- Joined: Fri Oct 22, 2010 12:46 am
- Location: Yorkshire, UK
Re: FS ability to call .dll's question
Thanks Trog,
You raised some 'ethic' issues I had not considered.
Your additional points, even though disappointing to read, stills helps in the understanding process, and using the 'best' programming technique for a given task.
The 'passing of parameters' to a dll has still got my interest. Leaving audio stream [RT] out of the picture, I was interested in using MIDI data, and sending that information directed to a specific VST [.DLL]. Basically a one-way communication from FS to said VST.
To clarify the 'housing' idea ... I had thought more along the lines like a 'VST Chainer' type app, where a user would load VST's into a chains 'slot'. The 'slot' would be assign a specific MIDI Channel enabling the VST to be 'isolated' and only receiving a specific channel. I'm dealing with a commercial VST that only has Global MIDI Ch implemented
Basically I'm exploring for a possible better solution than my current design.
You raised some 'ethic' issues I had not considered.
Your additional points, even though disappointing to read, stills helps in the understanding process, and using the 'best' programming technique for a given task.
The 'passing of parameters' to a dll has still got my interest. Leaving audio stream [RT] out of the picture, I was interested in using MIDI data, and sending that information directed to a specific VST [.DLL]. Basically a one-way communication from FS to said VST.
To clarify the 'housing' idea ... I had thought more along the lines like a 'VST Chainer' type app, where a user would load VST's into a chains 'slot'. The 'slot' would be assign a specific MIDI Channel enabling the VST to be 'isolated' and only receiving a specific channel. I'm dealing with a commercial VST that only has Global MIDI Ch implemented
Basically I'm exploring for a possible better solution than my current design.
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: FS ability to call .dll's question
So Mr.Hollins, how would you communicate the data back from the commercial plugin (.dll) to your FS one ?
Wouldn't you need to change the code in that .dll first? Unless it has an existing function that sends??
Wouldn't you need to change the code in that .dll first? Unless it has an existing function that sends??
- Drnkhobo
- Posts: 312
- Joined: Sun Aug 19, 2012 7:13 pm
- Location: ZA
Re: FS ability to call .dll's question
Drnkhobo wrote:So Mr.Hollins, how would you communicate the data back from the commercial plugin (.dll) to your FS one ?
Wouldn't you need to change the code in that .dll first? Unless it has an existing function that sends??
Hi Drnkhobo,
Actually ... I don't think I'd need 'feedback' data from the commercial plug [though it'd be nice].
Basically, I would need to send MIDI messages [Patch#, [CC] data, etc] to the plug [which has basic MIDI awareness].
The major issue I'm facing: This commercial plug [unless update mod'd] listens on all 16 MIDI channels. There is not an 'internal' Channel select . All my personal testing has been with Reaper DAW. Through the use of interspersed MIDI filter plugs [vst], I am able to 'isolate' the intended plugin. With the 'full blown' controller versions, this is 13 plugins PLUS 13 filter plugins.
This is all working very well ... but looks like a 'duck tape' job And interferes with certain DAW's that have limited plugin slots.
Another alternative is the use of 'VST Chainers', a single plugin that can house multiple. I have this working with Plouges 'Biddle', and METAPlugin. I still have to do the filtering, but that is contained in the Chainer.
I'm trying to think forward to a more 'elegant' solution.
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: FS ability to call .dll's question
I see, its a great idea actually, thanks for explaining!
LOL, I know those ones too!
I'd like to see what you end up with as I have thought of something similar. Just like TRacks for instance.
Unfortunately I didn't get anywhere (For my purpose FS needs to be changed to allow this) but good luck man!
Midi Filters perhaps???
This is all working very well ... but looks like a 'duck tape' job
LOL, I know those ones too!
I'd like to see what you end up with as I have thought of something similar. Just like TRacks for instance.
Unfortunately I didn't get anywhere (For my purpose FS needs to be changed to allow this) but good luck man!
Midi Filters perhaps???
- Drnkhobo
- Posts: 312
- Joined: Sun Aug 19, 2012 7:13 pm
- Location: ZA
Re: FS ability to call .dll's question
Drnkhobo wrote:I see, its a great idea actually, thanks for explaining!This is all working very well ... but looks like a 'duck tape' job
LOL, I know those ones too!
I'd like to see what you end up with as I have thought of something similar. Just like TRacks for instance.
Unfortunately I didn't get anywhere (For my purpose FS needs to be changed to allow this) but good luck man!
Midi Filters perhaps???
On the Reaper site, some 'smart guy' posted a JS script that does this filtering.
Wish I was smart enough to do this in FS.
The 'script' is open source, without limitations, and is free to modify.
I would like to have a standard VST plug that could do this Channel filtering for users of other DAW's.
I just don't fully understand this bit of JS script.
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
Re: FS ability to call .dll's question
I just don't fully understand this bit of JS script.
Why dont you post it here? Maybe someone knows a bit of js?
Im pretty sure Ruby can handle it nicely for you though, but I wouldnt be any help here, you need a Guru for that
- Drnkhobo
- Posts: 312
- Joined: Sun Aug 19, 2012 7:13 pm
- Location: ZA
Re: FS ability to call .dll's question
Drnkhobo wrote:Why dont you post it here? Maybe someone knows a bit of js?
If you can post a link, I'll take a peek; I've had a bit of a tinker with JS, so I might be able to get the gist of it.
All schematics/modules I post are free for all to use - but a credit is always polite!
Don't stagnate, mutate to create!
Don't stagnate, mutate to create!
-
trogluddite - Posts: 1730
- Joined: Fri Oct 22, 2010 12:46 am
- Location: Yorkshire, UK
Re: FS ability to call .dll's question
I can post the file here
Here's the latest version:
Here's the original release that I've been using, as I'm still testing the v2 release.
Would be curious to see comments thanks!
Here's the latest version:
Here's the original release that I've been using, as I'm still testing the v2 release.
Would be curious to see comments thanks!
- RJHollins
- Posts: 1571
- Joined: Thu Mar 08, 2012 7:58 pm
14 posts
• Page 1 of 2 • 1, 2
Who is online
Users browsing this forum: No registered users and 66 guests