Are loaded VST(i)s active anyway, no matter they are player/used?
I have a song with ~60 VSTIs loaded and 6-7 VST effects (the 1-1.3gig+ memory usage is another issue, but that is fine, i don't mind that =), but opening a new pattern, entering some notes and re-playing them even just one channel gives that processing-power-overflow-sound-cracking (or whatever is the exact term for that phenomena =). That is not nice (it's terribly annoying in the matter of fact =), and slows down the work, because i have to render the song to .wav every time i need to hear the achievements of my final work, or even the simple modifications.
If so, that shouldn't be that way IMO, VSTs should be only active, when they are "triggered" (by a note or something =).
As I know, all VSTis are active when play is pressed, no matter if the channels are muted. Guess you should address this in the requests subforum, since OMPT handles VST not as specification intended.
Holy mackerel! 60 VSTis!!! It can bring even most powerful machine to its knees!
Quoteno matter if the channels are muted
well, that is one issue (the muted channels), but the sound cracking comes (as i said) even if i open a new pattern, and enter just a few notes.
QuoteHoly mackerel! 60 VSTis!!!
well...yeah ^_^, you c, i'm using various basses, strings, leads etc., and filler effects. If i'm having example 8-10 specialFX, those are 8-10 independent VSTis, and that's only effects, where are the basses, percussion instruments, leads... ::)
QuoteIt can bring even most powerful machine to its knees!
It can? :lol: it does! my overclocked core2duo system is dying from 1 channel playback, now that IS funny. :lol:
Well, the VST(i) specification actually states that all plugins should *always* be active. The only way in which OpenMPT doesn't follow the specification is that it actually cuts them off when you hit stop, which is wrong. :)
What I would recommend doing is bypassing plugins that you're not working with at the time. If you use Xlutop chainer, you can even bind a plugin's bypassed state to a MIDI controller (as far as I know), which could be useful.
setting to bypass the unused ones when working? that sounds useful indeed (hope that it will reduce the CPU usage).
I always pack a bunch of VST effects to a single Chainer VST, but rarely using Chainer for the VSTis. I open an instance of the VSTi when i need some new instruments, and realize in the mid of the work, that i need another, and another, aaaand another...
Ohhhh, but the VST3 standard enables the plug-ins "only when audio signals are present on their respective inputs."
http://www.kvraudio.com/news/5933.html
this was so basic and logical to me, i wonder what was Steinberg thinking when invented/made the VST2 (currently in OMPT afaik) standars... ::)
So, VST3 standard support is desperately needed.
My CPU is on its knees because of the heavy number of powerful, all-the-time-active, VSTis. =)
If, my memory is not mistaken, we already have a topic about that in feature request forums, i'll +1 that one right now.
If the VSTs are well programmed in the first place, shouldn't their CPU consumption drop to nearly zero when they don't receive any input or produce any sound? And isn't this new functionality something to be implemented in the plugins as well as the host, which means if your plugins only support VST2 it won't help at all?
EDIT: removed wrongful text
Quote from: "älskling"Then there's that elephant hiding in the room, the VST code used in OpenMPT isn't really GPL is it?
If you're not referring to VST SDK,
please elaborate,
else
no, that is not GPL and not even compatible with it, but due to recent changes in OMPT, it does't have to be GPL.
Oh, I didn't know about the recent changes. Sorry for the misinformation then. :)
I've decided to try how other hosts are behaving in similar situations, so i did stuffed Renoise 1.9.1 demo, with VSTis till my real memory was near full, thats about 70+ instances there. That version from Renoise is VST2.x standard afaik, and the VSTi that i'm using is also VST2.x standard.
Tested with polyphony and one instance (filled with some random OSC routing, just to eat CPU) did produce about 3-6% CPU ussage. Sometimes a little more. After that i've quick tested with 6-7 instance, and CPU ussage went from 20-26% (with smooth playback of course), which is again, fine.
OMPT would suffer from crackling with the same setup.
However, i've noticed something called "Auto Suspender" in the Renoise instrument list, and it seems to suspend every instrument that isn't sensing audio processing. Turning that function off in every instrument produces about 35% or more CPU usage permanently (no notes playing), and about 60-70% with 7-8 instance playing together. If the playback is finished, the CPU usage is going back to that ~35%. Noticeable CPU usage rising, but still not a single crackling.
So the problem seems to be something else on OMPT, but i don't have idea what could cause so much difference. As far as i can tell, implementing a similar thing, like this "Auto Suspender", would already save a suffering user from a lot of head-ache, and maybe wouldn't be as complicated as messing yet again with the VST code. I'm not sure that bypassing the VST has the same effect in OMPT as "suspend" in Renoise.
Quote from: "älskling"Sorry for the misinformation then. :)
What was the misinformation -- to me it seemed quite valid :)
I'm only at 100 Mhz, so hi-CPU VSTi's are out of the question right now. I can use mid-CPU but no VST effects, especially Reverb and Equalizers. If i do run into playback skipping, i can mute the VSTi track and i get my CPU back, but any unmuted VST or VSTi channels grab my CPUs, even if they are not activated by any channel or instrument.
I'm sure we would all like to know from the devs (dev?) how high a priority they place on this particular problem.
Omg, since when did we made OpenMPT able to run on mobile phones? :shock:
I can remember that i had trouble having a simple stereo mp3 playback (got a CPU overload) on my 75-85mhz AMD 5x86, so i've had to downmix it to mono or 22050hz. It's a miracle imo that OMPT runs at these speeds and kickin'.
Modplug was created when these CPUs were still very common. It wasn't too comfortable to use on my 133Mhz machine, but yes, it worked, and it even works on a 486. Just without the VST stuff... :lol:
Old trackers still work on a 486, so why couldn't modplug do that too?
Honestly, the biggest limitation in this picture is not modplug, but the OS.
Quote from: "Jojo"Modplug was created when these CPUs were still very common. It wasn't too comfortable to use on my 133Mhz machine, but yes, it worked, and it even works on a 486. Just without the VST stuff... :lol:
No,no,no, you misunderstood.....
CPU in the sense of processor speed -- "clocks", or "ticks". We use the term as an alternate to "processor cycles."
i'm not sure if i got you..
It seems like you or psishock misunderstood what i meant when i said "If i do run into playback skipping, i can mute the VSTi track and i get my CPU back, but any unmuted VST or VSTi channels grab my CPUs..."
Then you said "when CPUs were still common." I don't know if CPU is an acronym for something else, but i meant it in the sense of clock ticks in one's processor, y'know, processor speed.
CPU = central processing unit
CPS = cycles per second
???
Don't misquote me. I never said that "cpus were common", but "these cpus were common" - and with that, i meant fast cpus versus slow cpus (as psishock was surprised that it works on a 100 mhz cpu).
I just took the quote right off the post, and didn't alter it. I wasn't even sure what you meant, which is why i thought i misunderstood. But if i understand you, you didn't misunderstand, i misunderstood and thought you misunderstood. Now i understand how i misunderstood, as i understand it.... :D
you didn't quote correctly, you missed one very important word:
QuoteModplug was created when these CPUs were still very common
and "these" were cpus like the 486er or pentium 1.
"These", "those", "this", "that", "the other" -- it doesn't matter, Jojo; no matter how what quantifier you used, i still didn't understand you, and i thought that led to psishock thinking something else. No other explanation is necessary. I'm sure you have more important things to worry about....