Hi, Welcome Robin! You have asked a question that has been at the back of my mind for a long time. Thanks! <snip>
Sure! Just create a simple file that just holds a line like this;
.8 => dac.gain;
This will affect the dac's gain, no surprise there, but as the dac is shared by all shreds this work more or less like a master fader. Replace the .8 by any number between 0 and 1, depending on how severe the clipping is, turn it down further if clipping re-occurs.
fadeout.ck exists I think. You can fadeout all of chuck with this method but it isn't great for smoothly dumping one shred while keeping the others active. <snip>
These two questions lead me to wonder if there is any way of exposing the implicit mixer prior to the DAC, so that levels and mutes on each channel/shred could be controlled.
What you could do is supply each shred with a envelope before the dac and have that one ramp down before making the shred itself exit, based on some command?
I like this suggestion. I would love to have some boilerplate code so that you could work with shreds in a kind of mixing environment where each shred had it's own volume control that could be *easily* (not necessarily simply) accessed from another place. I have used OSC in the past but I would love to see some other suggestions, possibly using command line arguments. This is a worthy tutorial for the manual ;) Anyone got something working? --art _________________________________________________________________ Former Police Officer Paul Gillespies TAKE BACK THE INTERNET tips and tricks, watch the video now http://safety.sympatico.msn.ca/
On 9/2/07, Adam Tindale
I like this suggestion. I would love to have some boilerplate code so that you could work with shreds in a kind of mixing environment where each shred had it's own volume control that could be *easily* (not necessarily simply) accessed from another place. I have used OSC in the past but I would love to see some other suggestions, possibly using command line arguments. This is a worthy tutorial for the manual ;) Anyone got something working?
Well, if it's ableton-like behaviour using files in the style of the OTF examples that you are after I might have a idea. It would go like this; You make your patch like normal except inbetween the dac and the rest you put a Envelope. Once the shred starts this envelope starts ramping up over some apropriate amount of time, say one bar of your piece. You could also make it wait for the next bar to start before fading. In addition to whatever else you do you add a shred that listens for one keyboard (hid) key, take something not normally used like "pause/break". Once this key gets pressed the script tries to Machine.add() the exact file you are writing, if unsuccesfull it resumes listening (this likely means a syntax error), if successfull it will make the same envelope ramp down again using the same period, then removes the parent shred (effectively killing itself as well). This means that now the pause key is more or less turned into the replace opperator for this shred. The good news is that we now have fades, the bad is that this will take twice as much cpu for the transition period. There might be more bad news like unforseen issues... I've had this idea in the back of my head for quite a while now but never got round to implementing it. Perhaps a usefull idea for some people? Kas.
The docs say that a new process is sporked, but no actual system process results (not on Win32 anyway). Is it accurate to call these "processes" in the usual definition of that term? Or are they OS threads? Or something different again? I would like to be accurate about this, and learn something of the underlying, um, processes in the bargain. Sorry for the flood of posts; I'll settle down soon. :-) -- robin ----- Robin Parmar robinparmar.com
I wrote:
As I add shreds to the VM the output overloads. Is there an easy way of tweaking the master out all at once, without individually editing each shred file?
Kassen replied:
Sure! Just create a simple file that just holds a line like this; .8 => dac.gain;
Doh! Of course. The solution is another shred. Makes complete sense. I wrote:
Killing a shred happens abruptly and not always too musically. How can this be done for nicer sonic output in performance?
Kassen replied:
That would depend on what "nice" means in your context. You can use a ChucK program that will use Machine. remove(int id) on the shred in question at some suitable moment?
The problem is finding a suitable moment. For tracks that are pads or atmospheres, or even for those that are dense with content, killing the shred sounds horrid. If I make a horrible sound I want it to be deliberate, not the byproduct of killing a shred. :-)
What you could do is supply each shred with a envelope before the dac and have that one ramp down before making the shred itself exit, based on some command?
That sounds like a plan. Adam Tindale wrote:
fadeout.ck exists I think. You can fadeout all of chuck with this method but it isn't great for smoothly dumping one shred while keeping the others active.
I may be able to learn from this but couldn't find it in the examples. Kas wrote:
You make your patch like normal except inbetween the dac and the rest you put a Envelope. Once the shred starts this envelope starts ramping up over some apropriate amount of time, say one bar of your piece.
I do not fully understand this method, but think that maybe a custom ugen in place of the envelope could incorporate the controls needed. If one subclassed Ugen it should be possible to make a unit that could be put before dac in each shred that needed it. But I cannot find any examples of creating a class from ugen. I have no idea what methods signatures etc. are in place.
In addition to whatever else you do you add a shred that listens for one keyboard (hid) key, take something not normally used like "pause/break". Once this key gets pressed the script tries to Machine.add () the exact file you are writing, if unsuccesfull it resumes listening (this likely means a syntax error), if successfull it will make the same envelope ramp down again using the same period, then removes the parent shred (effectively killing itself as well).
Wow, you totally lost me. :-) -- robin ----- Robin Parmar robinparmar.com
participants (3)
-
Adam Tindale -
Kassen -
robin.escalation