From: Florian J. <flo...@we...> - 2012-05-24 22:40:17
|
Hi i just got some free VSTs and tried them out im getting the following when trying out recorded automation. i assume this is okay and intended, as i got this as well with a older revision (before i touched automation stuff). RemoteVSTServer::setParameter (0,1): 0 events expected RemoteVSTServer::setParameter (5,0.196131): 0 events expected RemoteVSTServer::setParameter (5,0.09): 0 events expected it seems to completely work as expected, and like before. however, the vst plugin i tried generates many controller change events per time, but due to the fixed rate and the unique events, this is only processed pretty slowly (a quick slider jerk can take several seconds, while i can see the countdown on the console window) i assume this is a bug per design and cannot be fixed except by not usinbg dssi-vst (or native guis) right? summary: works, but i'd still want to try out FST instead of dssi-vsi ;) greetings flo |
From: Geoff B. <ge...@la...> - 2012-05-24 22:44:51
|
On 05/25/2012 12:05 AM, Florian Jung wrote: > summary: works, but i'd still want to try out FST instead of dssi-vsi;) again, +1 from me on that. dssi-vst doesn't seem to work with latest wine (1.5.x) whereas fst works fine we used to use fst years ago for vst didn't we? g |
From: Geoff B. <ge...@la...> - 2012-05-24 22:47:33
|
On 05/25/2012 08:46 AM, Geoff Beasley wrote: > we used to use fst years ago for vst didn't we? isn't that why you see **Not t be built: VST stc ** at the beggining of the build ?? |
From: Robert J. <spa...@gm...> - 2012-05-25 06:47:55
|
Hi Geoff, Sporadic mail replies... 2012/5/25 Geoff Beasley <ge...@la...>: > On 05/25/2012 08:46 AM, Geoff Beasley wrote: >> we used to use fst years ago for vst didn't we? Indeed we used to support fst > isn't that why you see **Not t be built: VST stc ** at the beggining of > the build ?? Correct. This is for fst, an old version of fst. ...since then fst was completely rewritten.. in a way that seems to be more or less a patch for ardour... last time I looked at it it was impossible to figure out how to support it in MusE. Which I believe is Tim's opinion as well... Regards, Robert > > ------------------------------------------------------------------------------ |
From: Tim E. R. <ter...@ro...> - 2012-05-25 20:16:04
|
On May 25, 2012 8:47:49 AM Robert Jonsson wrote: > Hi Geoff, > > Sporadic mail replies... > > 2012/5/25 Geoff Beasley <ge...@la...>: > > On 05/25/2012 08:46 AM, Geoff Beasley wrote: > >> we used to use fst years ago for vst didn't we? > > Indeed we used to support fst > > > isn't that why you see **Not t be built: VST stc ** at the beggining of > > the build ?? > > Correct. This is for fst, an old version of fst. > ...since then fst was completely rewritten.. in a way that seems to be > more or less a patch for ardour... last time I looked at it it was > impossible to figure out how to support it in MusE. Which I believe is > Tim's opinion as well... Mm, maybe not impossible, IIRC when I asked around I was told that it means MusE would need to be built as a Wine app or something, which kind of lost me as to how to do it... I think this may mean opening up MusE more to security issues vs. dssi-vst. Tim. > > Regards, > Robert |
From: Geoff B. <ge...@la...> - 2012-05-26 01:14:41
|
On 05/26/2012 06:15 AM, Tim E. Real wrote: > it means MusE would need to be built as a Wine app or something, oh shit, i forgot about that - forget it ! g |
From: Florian J. <flo...@we...> - 2012-05-26 15:20:26
|
Am 26.05.2012 03:16, schrieb Geoff Beasley: > On 05/26/2012 06:15 AM, Tim E. Real wrote: > >> it means MusE would need to be built as a Wine app or something, >> > oh shit, i forgot about that - forget it ! > no don't ;) can you explain that a bit more to me? what's "building as a wine app"? and can't we "simply" load the .dll somehow via WINE so that we can call the functions in there, and then, well, call them? as a very last resort, could we maybe write a windows-application which accesses the VSTs and exposes them via some network socket? and MusE then starts this app via wine and connects to the socket? greetings flo > g > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > |
From: Florian J. <flo...@we...> - 2012-05-26 21:31:36
|
maybe you also want to have a look on LMMS's solution for this: vestige? i haven't looked very closely at this, but maybe it might help us? greetings flo Am 26.05.2012 17:07, schrieb Florian Jung: > Am 26.05.2012 03:16, schrieb Geoff Beasley: >> On 05/26/2012 06:15 AM, Tim E. Real wrote: >> >>> it means MusE would need to be built as a Wine app or something, >>> >> oh shit, i forgot about that - forget it ! >> > no don't ;) > can you explain that a bit more to me? > > what's "building as a wine app"? > and can't we "simply" load the .dll somehow via WINE so that we can call > the functions in there, and then, well, call them? > > as a very last resort, could we maybe write a windows-application which > accesses the VSTs and exposes them via some network socket? and MusE > then starts this app via wine and connects to the socket? > > greetings > flo > >> g >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Lmuse-developer mailing list >> Lmu...@li... >> https://lists.sourceforge.net/lists/listinfo/lmuse-developer >> >> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > |
From: Robert J. <spa...@gm...> - 2012-05-27 21:57:25
|
2012/5/26 Florian Jung <flo...@we...>: > Am 26.05.2012 03:16, schrieb Geoff Beasley: >> On 05/26/2012 06:15 AM, Tim E. Real wrote: >> >>> it means MusE would need to be built as a Wine app or something, >>> >> oh shit, i forgot about that - forget it ! >> > no don't ;) > can you explain that a bit more to me? > > what's "building as a wine app"? > and can't we "simply" load the .dll somehow via WINE so that we can call > the functions in there, and then, well, call them? I'm not sure but I think that requires that MusE becomes a wine app (linking with the wine-gcc version somehow I think), or possibly that the library doing the loading is a wine lib. > > as a very last resort, could we maybe write a windows-application which > accesses the VSTs and exposes them via some network socket? and MusE > then starts this app via wine and connects to the socket? This seems no better than the currently supported solution with dssi-vst? By the way, when using dssi-vst, make sure to use the patch listed here: http://muse-sequencer.org/index.php/Faq#VST_support_through_DSSI_.2B_patch Regards, Robert |
From: Florian J. <flo...@we...> - 2012-05-27 22:08:28
|
Am 27.05.2012 23:57, schrieb Robert Jonsson: > 2012/5/26 Florian Jung <flo...@we...>: >> Am 26.05.2012 03:16, schrieb Geoff Beasley: >>> On 05/26/2012 06:15 AM, Tim E. Real wrote: >>> >>>> it means MusE would need to be built as a Wine app or something, >>>> >>> oh shit, i forgot about that - forget it ! >>> >> no don't ;) >> can you explain that a bit more to me? >> >> what's "building as a wine app"? >> and can't we "simply" load the .dll somehow via WINE so that we can call >> the functions in there, and then, well, call them? > > I'm not sure but I think that requires that MusE becomes a wine app > (linking with the wine-gcc version somehow I think), or possibly that > the library doing the loading is a wine lib. then let's do that? create a small library built as a wine-lib which can be loaded by muse if desired that also has the advantage that distributors can create a muse2 package which does not depend on wine, and a muse2-vst package which does. greetings flo > >> >> as a very last resort, could we maybe write a windows-application which >> accesses the VSTs and exposes them via some network socket? and MusE >> then starts this app via wine and connects to the socket? > > This seems no better than the currently supported solution with dssi-vst? > > By the way, when using dssi-vst, make sure to use the patch listed here: > http://muse-sequencer.org/index.php/Faq#VST_support_through_DSSI_.2B_patch > > Regards, > Robert > |
From: Robert J. <spa...@gm...> - 2012-05-27 22:02:40
|
2012/5/26 Florian Jung <flo...@we...>: > maybe you also want to have a look on LMMS's solution for this: vestige? vestige is a header-file, an effort to clean-room reverse engineer the vst specification. I think LMMS probably uses this to get native VST support, vst-plugins that are in linux format. They exist but there are not that many. > i haven't looked very closely at this, but maybe it might help us? Support for native VST would be nice too but I'm not sure it would help with supporting win32 VSTs. Now that I think about it. I believe dssi-vst also uses vestige, maybe I'm wrong with that it is only used for native support?! Regards, Robert |
From: Geoff B. <ge...@la...> - 2012-05-27 23:25:11
|
On 05/28/2012 08:02 AM, Robert Jonsson wrote: > Now that I think about it. I believe dssi-vst also uses vestige, maybe > I'm wrong with that it is only used for native support?! as I understand it vestige is a drop in replacement for Steinbergs's headers etc for standard windows VST's - not native VST's, which are VST's recompiled to run natively under Linux. I consider native VST's dead in the water from what I can see and supporting them is not important - LV2 is much more beneficial imo. g |
From: Geoff B. <ge...@la...> - 2012-05-27 23:32:22
|
On 05/28/2012 07:57 AM, Robert Jonsson wrote: > This seems no better than the currently supported solution with dssi-vst? except that current dssi-vst doesn't work here with wine 1.5.x and is not as stable as fst imo - however as I have previously noted, under MusE, dssi-vst is /_much_/ more reliable than standalone - go figure ! btw there's a fork of fst just released now that seems to work as well as the old fst but with new features. probably doesn't hel;p us any more than fst does, but at least it has an active dev now :) worth a look anyway - working fine here so far http://sourceforge.net/projects/fsthost/ g |
From: Florian J. <flo...@we...> - 2012-05-28 17:00:34
|
Am 28.05.2012 01:34, schrieb Geoff Beasley: > On 05/28/2012 07:57 AM, Robert Jonsson wrote: >> This seems no better than the currently supported solution with dssi-vst? > > except that current dssi-vst doesn't work here with wine 1.5.x and is > not as stable as fst imo - then use fst! > however as I have previously noted, under > MusE, dssi-vst is /_much_/ more reliable than standalone - go figure ! then implement fst (which i assume means the same as "standalone"?) correctly! > > btw there's a fork of fst just released now that seems to work as well > as the old fst but with new features. probably doesn't hel;p us any more > than fst does, but at least it has an active dev now :) cool. why exactly doesn't it help us again? > > worth a look anyway - working fine here so far > > http://sourceforge.net/projects/fsthost/ i'll have a look; would be great if we could use it ;) greetings flo > > > g > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer |