Hi there,
Since I owned Z2, I can't use program change with Live. When the 2.1 came, I thought... Oh yeah! the new version... for sure the prog change is now implemented... yes, for sure... in my dreams!
I had a look here and all I can see is "use the rack, bla bla bla...".
What a stupid situation to put 16 Zebras in a rack, to have 16 sounds... why not 16 computers, each one with a different sound?... in 2007, it's ridiculous.
Urs, can't you just do it? Is it so big deal?
I didn't look at the specs before I bought it, just because I thought it was an essential function that all virtual synth should have... now I regret it. If I just knew there was no prog change, I'd never spent my money. It's a shame for a 199€ plug-in, just NOT PROFESSIONAL at all!
BTW I love the sound, so I'm just sorry to not use it(yes... I bought it, and I don't use it!)
So, would you please consider the request, Urs, and do what it's possible to?
Greetz.
Greg
What the Hell with Midi Program Change ?
-
- KVRAF
- 26968 posts since 3 Feb, 2005 from in the wilds
Actually, the rack solution works nicely. Not only can you switch between Zebra instances, but each of those instances can have their own effects chain which is an added advantage.
Sure it would be nice to be able do program changes, but until they are there, there is a viable workaround.
Sure it would be nice to be able do program changes, but until they are there, there is a viable workaround.
-
- u-he
- 30215 posts since 8 Aug, 2002 from Berlin
Greg, I'd love to do it if it wouldn't crash.
Program Changes are sent via Midi. Midi frequently comes in into the plugin on a so-called realtime thread. The Midi routine has to return as fast as possible. Changing a preset in Zebra takes time, up to half a second. If the Midi thread is blocked for such a long time, some hosts simply crash.
-> Program Changes = no go for a complex synth like Zebra
(can you change Reaktor ensembles via Midi?)
I might have a workaround for this, but I currently have no time to try it out now, maybe in a few months.
Urs
Program Changes are sent via Midi. Midi frequently comes in into the plugin on a so-called realtime thread. The Midi routine has to return as fast as possible. Changing a preset in Zebra takes time, up to half a second. If the Midi thread is blocked for such a long time, some hosts simply crash.
-> Program Changes = no go for a complex synth like Zebra
(can you change Reaktor ensembles via Midi?)
I might have a workaround for this, but I currently have no time to try it out now, maybe in a few months.
Urs-
- u-he
- 30215 posts since 8 Aug, 2002 from Berlin
Exactly that can happen with Program Changes. Not just in Zebra.uber909 wrote:I CAN'T have a computer bug on stage, in front of a thousand people...
-
- KVRer
- Topic Starter
- 4 posts since 25 Nov, 2006
For now I'm using Refx Vanguard, and no problem with prog change.
Honestly, I prefer Z2 sounds... but I just can't change presets manually on stage, so I've chosen Refx ergonomics...
Hopefully one day, I'll do another switch for Zebra.
Honestly, I prefer Z2 sounds... but I just can't change presets manually on stage, so I've chosen Refx ergonomics...
Hopefully one day, I'll do another switch for Zebra.
-
- KVRAF
- 26968 posts since 3 Feb, 2005 from in the wilds
If it does not work for you I understand... have you tried though?uber909 wrote:I agree, but it's a question of CPU charge an ergonomics.
I CAN'T have a computer bug on stage, in front of a thousand people...
If you use switches (buttons) to turn rack chains on and off, there is no extra cpu use and I have never had it crash on me.
My controller has a row of buttons with led. Each button turns a chain on or off. Each chain is a zebra instance with own preset and effect chain.
You press one button to turn off current chain, press the next button to turn on the next chain... all from the controller. No mousing.
You can do as many presets as you have dedicated buttons on your controller and as I said, the advantage is that you can change the whole chain at once
zebra - mfm2 - saturator - compressor - reverb
to
zebra - filterscape - compressor - mfm2
or whatever your choices. I think it is efficient even for stage use.
-
- KVRist
- 61 posts since 4 Oct, 2006 from MD, USA
Urs, sorry, couldn't resist. I'm not by all means in position to give developer advice even if I knew the internals of Z2. But if I may, I would put the program change request in a queue and return immediately. Other thread (either started on the queue add or just waiting on the queue) would have all the time to change the program and quit or wait again. I don't know, may be it is indeed the workaround you are talking about.Urs wrote:Greg, I'd love to do it if it wouldn't crash.
Program Changes are sent via Midi. Midi frequently comes in into the plugin on a so-called realtime thread. The Midi routine has to return as fast as possible. Changing a preset in Zebra takes time, up to half a second. If the Midi thread is blocked for such a long time, some hosts simply crash.
-> Program Changes = no go for a complex synth like Zebra
(can you change Reaktor ensembles via Midi?)
I might have a workaround for this, but I currently have no time to try it out now, maybe in a few months.
-
- u-he
- 30215 posts since 8 Aug, 2002 from Berlin
michkohl, that's exactly what I got in my mind.
However, I'd have to start an additional low priority timer in the user thread, ideally globally to all instances - which I had hoped to avoid.
Another problem is, the preset stuff is located in the gui part. I'd have to rewrite the code to be usable in a more general way so that the file objects can also be accessible in the dsp part. (Background info: Regardless of plugin API, there is no pointer reference between gui and dsp in my plugins, just a neat & safe messaging system, thus I have to come up with some clever design here...)
Thing is, even though the general idea sounds easy, there are some obstacles.
Cheers,
Urs
However, I'd have to start an additional low priority timer in the user thread, ideally globally to all instances - which I had hoped to avoid.
Another problem is, the preset stuff is located in the gui part. I'd have to rewrite the code to be usable in a more general way so that the file objects can also be accessible in the dsp part. (Background info: Regardless of plugin API, there is no pointer reference between gui and dsp in my plugins, just a neat & safe messaging system, thus I have to come up with some clever design here...)
Thing is, even though the general idea sounds easy, there are some obstacles.
Cheers,
Urs-
- KVRist
- 61 posts since 4 Oct, 2006 from MD, USA
Urs, thanks for the reply. I wish I knew the internals better. (It seems one way is to send a "program-change" message from dsp to gui asynchronously, gui would do the rest.) Zebra is a great product, please take all time you need. 
-
- u-he
- 30215 posts since 8 Aug, 2002 from Berlin
That's a safe way, but it has a serious problem: The gui must be open for it to workmichkhol wrote:(It seems one way is to send a "program-change" message from dsp to gui asynchronously, gui would do the rest.)
While the dsp objects exist over the whole life cycle of an instance, the gui objects only exists while the editor is open. (Sidenote: A special requirement for Audio Units and supposedly for upcoming VST3 is that gui and dsp must be able to run on two different processes/machines, meaning a total encapsulation of each and the ability of one to run without the presents of other one)
Thus, hehehe, I have to fold the preset handling back to the dsp... even though the presets visible for the dsp part can be different ones from those in the gui (if dsp & gui run on different machines)...
As I said, it is a complex problem. Plugin stuff is full of these ambivalent things, sometimes it hurts
Cheers,
Urs-
- KVRist
- 61 posts since 4 Oct, 2006 from MD, USA
I can only imagine... So the dsp object gets two parts, real-time and low priority with asynchronous messaging from former to latter and synchronous one in opposite direction. The low-priority part handles presets and gui communication. The gui has its own preset management and is able to control, send and receive the presets on/to/from the different machine...Urs wrote:
Thus, hehehe, I have to fold the preset handling back to the dsp... even though the presets visible for the dsp part can be different ones from those in the gui (if dsp & gui run on different machines)...
As I said, it is a complex problem. Plugin stuff is full of these ambivalent things, sometimes it hurts
Cheers,
Sorry, Urs, I'm getting carried away... Won't bother you again with all these technicalities.
-
- KVRist
- 381 posts since 27 Sep, 2006 from Eastern US
Hello Urs,
I too, would love to see Zebra2 handle program changes as it would be a good way to peruse all the presets with just a MIDI keyboard, assuming it handles bank changes as well.
A couple of thoughts on this.
It would be okay with me if Zebra only did program changes if the editor was open. A small price to pay.
Or alternatively, on the mac at least, perhaps you could simply call InstallEventLoopTimer on the main event loop (GetMainEventLoop). Then just do everything when the timer fires. This would alleviate any need to create a new thread.
Thanks,
Jeremy
I too, would love to see Zebra2 handle program changes as it would be a good way to peruse all the presets with just a MIDI keyboard, assuming it handles bank changes as well.
A couple of thoughts on this.
It would be okay with me if Zebra only did program changes if the editor was open. A small price to pay.
Or alternatively, on the mac at least, perhaps you could simply call InstallEventLoopTimer on the main event loop (GetMainEventLoop). Then just do everything when the timer fires. This would alleviate any need to create a new thread.
Thanks,
Jeremy
-
- u-he
- 30215 posts since 8 Aug, 2002 from Berlin
Yes. I would by all means avoid opening a new thread.SaganTech wrote:Or alternatively, on the mac at least, perhaps you could simply call InstallEventLoopTimer on the main event loop (GetMainEventLoop). Then just do everything when the timer fires. This would alleviate any need to create a new thread.
On MacOS X I would have no problems with a single RunLoopTimer for *all* instances.
Really, my only gripe is, it should also work with editor closed (for those who use program changes within a song/production even...) and thus I have to wade through tens of files to make preset handling available within the dsp part, and to have it safely synchronized with the gui.
Another issue is the overall design.
I think I would have a single special folder of presets which is the program change list. The presets in this folder would be compiled to a binary representation of Zebra's state that is compatible with the current version (the actual preset format is version independent even though the parameter list etc. can change from time to time). The binary state can probably be activated a magnitude faster than the normal preset...
Hmmm...