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
Plugin disabled = Ruby disabled
17 posts
• Page 2 of 2 • 1, 2
Re: Plugin disabled = Ruby disabled
matti wrote: There needs to be a distinct line drawn between realtime and non-realtime tasks! This along with VstParameter ordering are the biggest shortcomings of FS at the moment.
FS team! Kick yourself to do something about these
You forgot to mention the "secret" Ruby DLL install/copy into the app data (or whatever) folder too. That to me is a huge problem...(Unless thats already fixed? I can't find the fix mentioned anywhere)
- VPDannyMan
- Posts: 118
- Joined: Mon Jan 04, 2010 4:50 am
Re: Plugin disabled = Ruby disabled
VPDannyMan wrote:matti wrote: There needs to be a distinct line drawn between realtime and non-realtime tasks! This along with VstParameter ordering are the biggest shortcomings of FS at the moment.
FS team! Kick yourself to do something about these
You forgot to mention the "secret" Ruby DLL install/copy into the app data (or whatever) folder too. That to me is a huge problem...(Unless thats already fixed? I can't find the fix mentioned anywhere)
Oh, yeah. That aint cool either. Nor is the way using .dll files with Ruby. The idea is great but the additional crap that needs to be installed along with a plugin that uses that feature is just silly (subfolders++).
- matti
- Posts: 55
- Joined: Fri Sep 24, 2010 12:06 pm
Re: Plugin disabled = Ruby disabled
Got trogluddite's report on this. Definitely needs sorting so leave it with us.
I know this mechanism is not ideal for everyone but it's no more secret than populating the registry or creating other files in App Data just like any other Windows application. We're not trying to hide anything it's just the only way we could find so far to allow you to export a single exe or dll and take Ruby with you. We'd rather have that than not allow it at all.
Anyway, we have been looking into ways of doing this better. After alot of headaches we have seen some progress and managed to get it to statically link. However, Ruby isn't working correctly when we do this so there is some more work to be done. It's taking a while but we're having to work on this in parallel with other things.
Agreed. However, again we thought it would be better to have it like this than nothing at all. Certainly for audio there are better, cleaner ways of doing this and hopefully we can bring them to you in good time.
VPDannyMan wrote:You forgot to mention the "secret" Ruby DLL install/copy into the app data (or whatever) folder too. That to me is a huge problem...(Unless thats already fixed? I can't find the fix mentioned anywhere)
I know this mechanism is not ideal for everyone but it's no more secret than populating the registry or creating other files in App Data just like any other Windows application. We're not trying to hide anything it's just the only way we could find so far to allow you to export a single exe or dll and take Ruby with you. We'd rather have that than not allow it at all.
Anyway, we have been looking into ways of doing this better. After alot of headaches we have seen some progress and managed to get it to statically link. However, Ruby isn't working correctly when we do this so there is some more work to be done. It's taking a while but we're having to work on this in parallel with other things.
matti wrote:That aint cool either. Nor is the way using .dll files with Ruby. The idea is great but the additional crap that needs to be installed along with a plugin that uses that feature is just silly (subfolders++).
Agreed. However, again we thought it would be better to have it like this than nothing at all. Certainly for audio there are better, cleaner ways of doing this and hopefully we can bring them to you in good time.
-
support - Posts: 151
- Joined: Fri Sep 07, 2012 2:10 pm
Re: Plugin disabled = Ruby disabled
support wrote:Got trogluddite's report on this. Definitely needs sorting so leave it with us.VPDannyMan wrote:You forgot to mention the "secret" Ruby DLL install/copy into the app data (or whatever) folder too. That to me is a huge problem...(Unless thats already fixed? I can't find the fix mentioned anywhere)
I know this mechanism is not ideal for everyone but it's no more secret than populating the registry or creating other files in App Data just like any other Windows application. We're not trying to hide anything it's just the only way we could find so far to allow you to export a single exe or dll and take Ruby with you. We'd rather have that than not allow it at all.
I agree that isn't as bad as it sounds. Lot's of installers do similar things. Making users more aware of the fact would've helped i guess. I think this thing had the unfortunate side-effect of making different version FS plugins to crash hosts too. Still, i don't see this as urgent as other issues mentioned.
support wrote:matti wrote:That aint cool either. Nor is the way using .dll files with Ruby. The idea is great but the additional crap that needs to be installed along with a plugin that uses that feature is just silly (subfolders++).
Agreed. However, again we thought it would be better to have it like this than nothing at all. Certainly for audio there are better, cleaner ways of doing this and hopefully we can bring them to you in good time.
True true. I have to admit i prefer having it with crazy stuff added than not at all
Even though we now have found some parts to complain about, you have still always moved forward. That is the most important thing. Keep it up
- matti
- Posts: 55
- Joined: Fri Sep 24, 2010 12:06 pm
Re: Plugin disabled = Ruby disabled
Oh and i forgot to mention: Debugging is pain in Ruby
It's cool that it lets you know something is wrong.. but no indication of what line the error occured at.
Btw. I wen't to great lengths to remove all Ruby code from my latest creation, just so that I'd avoid any crashes. Nice reminder of how useful that thing is. Making stuff in Ruby is sometimes so much faster
It's cool that it lets you know something is wrong.. but no indication of what line the error occured at.
Btw. I wen't to great lengths to remove all Ruby code from my latest creation, just so that I'd avoid any crashes. Nice reminder of how useful that thing is. Making stuff in Ruby is sometimes so much faster
- matti
- Posts: 55
- Joined: Fri Sep 24, 2010 12:06 pm
Re: Plugin disabled = Ruby disabled
More minor bugs in FS:
1. Date primitive has instructions on it: 0=Jan, 1=Feb.. When in fact 1=Jan, 2=Feb..
2. Trigger Switch primitive seems to default to False position when loading up a plugin.. even though it's input is True.
1. Date primitive has instructions on it: 0=Jan, 1=Feb.. When in fact 1=Jan, 2=Feb..
2. Trigger Switch primitive seems to default to False position when loading up a plugin.. even though it's input is True.
- matti
- Posts: 55
- Joined: Fri Sep 24, 2010 12:06 pm
Re: Plugin disabled = Ruby disabled
VPDannyMan wrote:You forgot to mention the "secret" Ruby DLL install/copy into the app data (or whatever) folder too. That to me is a huge problem...(Unless thats already fixed? I can't find the fix mentioned anywhere)
I know you (DSPR) were not trying to be secretive, it just appears that way when a user uses one of the plugs made with FS.
- VPDannyMan
- Posts: 118
- Joined: Mon Jan 04, 2010 4:50 am
17 posts
• Page 2 of 2 • 1, 2
Who is online
Users browsing this forum: Google [Bot] and 58 guests