CreamWare-Live Glitch-Avoidance Guide
The first challange: to use a CreamWare three card system, (two Pulsar 1's and a Luna II) to provide effects for an eight to 32 channel live sound system.
Second challenge: plus mixing.
Third challenge: plus VDAT, plus synths, etc.
What CreamWare Scope and third party devices 'mis-behave' by causing a glitch in the overall sound? What devices seem rock solid regardless of what you do?
Please share your glitch experiences with devices that might be used in a live-sound environment. Are there tricks for avoiding the glitch, e.g. avoiding insert slots for a particular device?
Another type of glitch might be the 'all-ice-cream-dinner' syndrome where devices that sound great by themselves, get muddy in the mix. But only if such behavior is blatant.
The main goal of the thread is keeping multiple channels of sound going through the Scope environment for a few hours without loss, crackle or blzzzt.
best,
john
CreamWare-Live Glitch-Avoidance Guide
Mm I've only ever had glitches because of low ULLI settings and clipping. You can solve the ULLI part by putting a higher value, and you can solve the clipping part by inserting a Soft Clip module (or limiter I guess) wherever signal overload might be a problem.
As for get-muddy-in-the-mix part, this is just a matter of proper EQing. Shouldn't be a problem if you prepare your EQ settings beforehand, or have a mixer/surface to tweak them live.
I guess there's also ADAT glitches, which aren't a problem with a proper slave/master setup. Can't say I've ever had glitching while using ZLink.
Otherwise I've never had much glitching going on while using my system. In fact I tend to laugh at all the poor all-native setups that start glitching when CPU load is too high. I've read some articles related to the benchmarking of dual core systems in relation to how much plugins you can use before the glitching starts, and couldn't stop laughing. All I could think about was how even my old k6-2 350 system (with VIA chipset motherboard!) was more reliable glitching-wise than any modern highly souped up dual core system.
This is why garanteed/dedicated processing will always be invariably better than native processing. I guess if OS vendors work at it a bit, they could cook up some garanteed/priority stuff to prevent the glitching, but I really don't see this happening on the Windows side of things. OSX seems to have some priority stuff, i.e. a process can request a certain amount of processing/clock ticks/timeslices to be garanteed in the following X timeslices, which is definitely a step in the right direction.
Now that I think about it, I've noticed some glitching in some situations, for example when using fast modulation on the panning of the Prisma synth. This also depends on the shape of modulation tho, i.e. using a sawwave to modulate things (pan, amplitude) might glitch as there is a pretty sudden jump of values. This kind of stuff isn't Creamware specific either, and is more a matter of properly setting things up. You can get similar stuff if you set for example the amplitude envelope's attack to 0, all modern synths I've tried this on generates a click at the beginning, which is logical, and sometimes desirable, but usually I tend to use a higher attack value to remove the click but keep the punch.
As for get-muddy-in-the-mix part, this is just a matter of proper EQing. Shouldn't be a problem if you prepare your EQ settings beforehand, or have a mixer/surface to tweak them live.
I guess there's also ADAT glitches, which aren't a problem with a proper slave/master setup. Can't say I've ever had glitching while using ZLink.
Otherwise I've never had much glitching going on while using my system. In fact I tend to laugh at all the poor all-native setups that start glitching when CPU load is too high. I've read some articles related to the benchmarking of dual core systems in relation to how much plugins you can use before the glitching starts, and couldn't stop laughing. All I could think about was how even my old k6-2 350 system (with VIA chipset motherboard!) was more reliable glitching-wise than any modern highly souped up dual core system.
This is why garanteed/dedicated processing will always be invariably better than native processing. I guess if OS vendors work at it a bit, they could cook up some garanteed/priority stuff to prevent the glitching, but I really don't see this happening on the Windows side of things. OSX seems to have some priority stuff, i.e. a process can request a certain amount of processing/clock ticks/timeslices to be garanteed in the following X timeslices, which is definitely a step in the right direction.
Now that I think about it, I've noticed some glitching in some situations, for example when using fast modulation on the panning of the Prisma synth. This also depends on the shape of modulation tho, i.e. using a sawwave to modulate things (pan, amplitude) might glitch as there is a pretty sudden jump of values. This kind of stuff isn't Creamware specific either, and is more a matter of properly setting things up. You can get similar stuff if you set for example the amplitude envelope's attack to 0, all modern synths I've tried this on generates a click at the beginning, which is logical, and sometimes desirable, but usually I tend to use a higher attack value to remove the click but keep the punch.