Hi, Robin!<br><br>On 9/1/07, <b class="gmail_sendername">robin.escalation</b> <<a href="mailto:robin.escalation@acm.org">robin.escalation@acm.org</a>> wrote:<div><span class="gmail_quote"></span><div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As I add shreds to the VM the output overloads. Is there an easy way<br>of tweaking the master out all at once, without individually editing<br>each shred file?</blockquote><div><br>Sure! Just create a simple file that just holds a line like this;
<br><br>.8 => dac.gain;<br><br>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.
<br><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Better yet, is there a way of making the shreds<br>"output-sensitive" so they adjust automatically using some standard
<br>audio amplitude summing law?</blockquote><div><br>Hmmmm, not that I can think off because the aproach needed there would depend heavily on the sittuation.<br><br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Killing a shred happens abruptly and not always too musically. How<br>can this be done for nicer sonic output in performance?</blockquote><div><br>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?<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">These two questions lead me to wonder if there is any way of exposing
<br>the implicit mixer prior to the DAC, so that levels and mutes on each<br>channel/shred could be controlled.</blockquote><div><br><br>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?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">A further usability issue was revealed when I tried to use a patch<br>from the examples folder that required sound files. These were
<br>referred to by relative pathing, but this only works if the script is<br>run in its own folder. It appears there is no way to programmatically<br>specify the root folder. So how does one integrate patches like this<br>
into a miniAudicle session?</blockquote><div><br>Yes, this is a known issue. What you would do in that case is set the folder containing the programs as being the folder from which the Mini looks for files (this is in the Mini's settings menu). Part of the question is that the Mini can't asume all code comes from loaded files because it might have been written in the Mini itself. Somebody needs to come up with a good idea to solve that.
<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thanks for your help with these very practical issues. I will be<br>writing an article soon on ChucK for my blog diagrammes modernes, so
<br>will incorporate any tips.</blockquote><div><br>Excelent, do post a link to your blog to the list when you do.<br><br>Kas.<br> </div><br></div>