Changing Patches in Z2

Official support for: u-he.com
Post Reply New Topic
RELATED
PRODUCTS

Post

Well, i knew it wouldnt take long before i had to ask some advice!

Im getting some awful carry-overs when changing presets. Im not doing it fast or anything, but quite often im having to wait around 3-5 seconds depending on the previous patch before i can safely select another without encountering sonic remnants/distortion left behind from the last one. Quite a few have reverb tails/delays etc..but its doing it on short presets too. I had this on occasion in TC's M42 Nebula, with notes hanging on into the next patch as if there is a Midi issue here with stuck notes, but nowhere else since - until today with Zebra. (Fantastic as she is...i think ive pi**ed her off a bit today somehow)!!

My setup is:

SONAR 8PE 8.3.1
AUDIO KONTROL 1
EDIROL PCR-500

AMD Dual 5200+
2.7GHZ
4GB Memory
1.5TB HD
WinXP SP3.

Any tips/advice appreciated. Btw - ive unchecked reset midi on stop (or whatever its called within SP8) but its happening i'd say 3 or 4 times out of every ten patches changed. :(

Post

I'll add an optional global reset at some point... it's been on the list for a while...

The idea with not resetting the effects was, you can change patches with different arpeggiator patterns on the fly. Unfortunately this has the unpleasant side effect that some combinations of changing from one preset to the next may result in noise bursts and what not.

Another idea is to simply use "Bypass FX" and browse without any effects.

;) Urs

Post

Urs wrote:I'll add an optional global reset at some point... it's been on the list for a while...
I'm not entirely sure what you mean by "global", but why not have each patch decide if the reset occurs or not, rather than having all patches subject/not-subject to the setting?

Post

billstei wrote:
Urs wrote:I'll add an optional global reset at some point... it's been on the list for a while...
I'm not entirely sure what you mean by "global", but why not have each patch decide if the reset occurs or not, rather than having all patches subject/not-subject to the setting?
Well, a side effect of the goodness of modularity is that the modules are black boxes to each other. Hence they don't really know what's going on in the patch and how they affect other modules. Thus they can't make any such decisions.

I've thought about it... one idea I always had was fading out the old sound to prevent clicks, but that would mean a timer based patch change, which is an idea I don't really like.

I think the only viable way is to optionally clear all buffers and maybe just restart all notes that have currently been played.

The other "big" option is adding multitimbrality so that notes held with the previous patch will just play until released. But that's a serious cpu killer with Zebra's kind of architecture...

Will think about it a bit more... still too involved in some Zebrify related stuff currently

Post

Urs wrote:I'll add an optional global reset at some point... it's been on the list for a while...


Another idea is to simply use "Bypass FX" and browse without any effects.

;) Urs

OK thanks Urs - i will bypass fx until then.

Post

Urs wrote:
billstei wrote:
Urs wrote:I'll add an optional global reset at some point... it's been on the list for a while...
I'm not entirely sure what you mean by "global", but why not have each patch decide if the reset occurs or not, rather than having all patches subject/not-subject to the setting?
Well, a side effect of the goodness of modularity is that the modules are black boxes to each other. Hence they don't really know what's going on in the patch and how they affect other modules. Thus they can't make any such decisions.

I've thought about it... one idea I always had [...]
Here is another idea I had: Have more than one *kind* of Zebra patch, the normal kind, and an Arpeggiator Data Only kind that does not make any changes/interruptions to the current voice (per se).
Urs wrote: Will think about it a bit more... still too involved in some Zebrify related stuff currently
I appreciate that you are willing to openly brainstorm with your end users, and I would rather spend time doing that than making "feature" requests. Please smack me on the side of the head with a large trout if I ever do otherwise. So we have FRs (feature requests), BRs (bug reports), and BSs (brain stormings). Or maybe BFs (brain fartings) - we need to brainstorm about the proper acronym.

Post Reply

Return to “u-he”