hi there.
i’m working on a plug i wich should host other plug ins.
some plug ins dont work when i compile my host in a vst plug in,
but the same plug ins work when i compile them to a standalone exe.
am-track_SE.dll
it caouses a an write exception in : juce_VSTPluginFormat.cpp @line 839:
soon after posting this, i came to the conclusion that it might have something to do with the “audioMaster” function ,and the fact that it is declared globally and static, and used by both , the host-plugin(via juce vst_wrapper) and the plugin-plugin(via the vst_plugininstance).
maybe some internal confusion between host-plugin entry point and plugin-plugin entry point(?) im not hsure, i’ more a “use the framework/UML” guy, i have not so much expeince with those (lower level) matters :oops:
.its JUCE code anywasy, so i dont want to alter it (also it may have to be done? i’ll certainly try and commit changes if i can do something) want to touch it.
crazy? since when is a chainer plug in so crazy, or a host wich is a plug in?
as much as i like your framework and coding style, we seem to have very different views here
how much time/energy do you dedicate to JUCE atm?
its more of a after work project i guess?
I know for a fact that Cycling’74 has released thier latest version, which is a major rewrite, of Max/MSP using JUCE. I trust these guys to have done thier homework and made an intelligent choice. That’s good enough for me.
I know for a fact that Cycling’74 has released thier latest version, which is a major rewrite, of Max/MSP using JUCE. I trust these guys to have done thier homework and made an intelligent choice. That’s good enough for me. :)[/quote]
hey, i did not want to question JUCE in its whole form. i was just curious how actively developed JUCE is by its creator, and how much of interest it is for him, to know what to expect in terms of developement speed and dedication, not to decide wether to buy it or not. i’m a big fan of the gui widgets and more, and i’m confident in having done the rigtht choice , wether brand xy is using it or not
my point is , i was hoping to get the vst-asio thing to get encapsuled away for me, as i want to focus on the over all design of my software first, not on the detail or otpitmization, because i’m pretty unexpreienced when it comes to the stuff i have to deal with now by my self (i wanted to du it afterwards, whe i’m shure the concept is tight), as jules seems not very interested in my posts lately (hey, just my impression form reading it .i get the feel he reads my posts like this:"
, mhhh. copy buffer?.. noob!..try again noob!"
i have no hard feelings (except by those wich are caused by my headache caused by my problem, nothing personal. i don’t put much personality weight in my interpretation of web post, as they may be totally wrong ;))
i still think juce will be a worth to buy a license, as i feel very compfrotable with the GUI stuff, and the generall structure of the audio stuff si great too, but i may have reached its boundarys earlyer than i though/hoped. mabye or (i hope) probably) these are just the boundarys if the way i’m thinking about the stuff, so i could improve my thinking by the help of the responese to the questions i post here rather then relying on JUCE being further developed to my needs. but the responses where really not of help at all lately :(. (except for the post by hydxn, i’ll post a replay to that post next. he gives me at least a tad of direction to navigate my brain to)
…phew…i hope you get the picture…i must go back to work…and post a reply do hydxn…
Sorry, I intended “crazy” to be interpreted as in “wacky” or “wild”, not crazy as in “stupid” or “hopeless”… It’s obviously a really interesting thing to try, and I’d be keen to see if you get it going. But I can’t think of much else to suggest without more info, and haven’t time to try doing the same thing myself right now.
I get a lot of posts to answer, as well as a lot of emails, and make a living from my own (juce-based) projects and contracts, so time is short. Apologies if I can’t give a perfect answer based on a particular post, but I’d rather post some kind of reply than just ignore it.
P.S. That “Juce users page” on the website is a couple of years out of date now - there’s many many more that need adding to it if I ever get chance…
cool, so JUCE is still you main baby
then of course i can image you hava a lot to do
peace!
i’ll try the pluggo max thingy and see wether they suffer from the same problem (afair i read that it has many problems hosting plug ins ins plugins too, maybe wen can join forces then :D)
I will soon also do a project like you, DasDeck, that is a VSTi plugin that can host VSTi plugins. If I run into problems, I’ll post them here for sure
yes - i regard that as a very powerful and meaningful thing, too. not in any way arcane or something. kind of like the subhost functionality of energyXT. …or think of Tracktions ‘rack-filters’ - just as a plugin for those who choose to use a less powerful host application .
may it be that i was supposed to exclusively inlcude the juce_VSTPluginFormat.h/cpp in my project in the first place :oops: ? i expected them to be linked into my plug-in from the juce lib file?
anyways, if i do so, it passes the write exception at the line i posted above. (seems like the audiomaster was never declared/defined before that)
but it still fails (or would fail if i did not modifie juce_VSTPluginFormat.cpp, see below) .
JUCEApplication::getInstance() returns 0 so exception of course,
soi just changed it to (i don’t mind if some name is broken, i could change it manuelly anyways know i guess):
but i guess JUCEApplication::getInstance() is expected to return something (my host? the plug in?), so you might want look into it
anyways. vst inside vst works now, and the host code seems nice and stable
I am wondering about the thread safety of VSTPluginInstance. I am attempting to use several instances of VSTPluginInstance running on different threads and I sometimes get a jassert in the VSTPluginInstance destructor. Looking at the juce_VSTPluginFormat source code, it seems that the use of the variable “insideVSTCallback” is not thread-safe since it is a static int – meaning that all threads will be touching the same variable.
Except for the occasional jassert, using several instances of VSTPluginInstance seems to work. For what I’m working on, it’s not absolutely essential that I use multiple threads, but I would like to use all the available cores if possible.