Do I downloaded the new ASIO patch to version 1.2.1.0 and everything worked perfectly in Windows XP feeding an RME Fireface. Congrats to all for making this such an exciting application! I look forward to live coding experiments using miniAudicle but have a couple of questions of a newbie nature. 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? Better yet, is there a way of making the shreds "output-sensitive" so they adjust automatically using some standard audio amplitude summing law? Killing a shred happens abruptly and not always too musically. How can this be done for nicer sonic output in performance? 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. A further usability issue was revealed when I tried to use a patch from the examples folder that required sound files. These were referred to by relative pathing, but this only works if the script is run in its own folder. It appears there is no way to programmatically specify the root folder. So how does one integrate patches like this into a miniAudicle session? Thanks for your help with these very practical issues. I will be writing an article soon on ChucK for my blog diagrammes modernes, so will incorporate any tips. ----- Robin Parmar robinparmar.com
Hi, Robin!
On 9/1/07, robin.escalation
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?
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. Better yet, is there a way of making the shreds
"output-sensitive" so they adjust automatically using some standard audio amplitude summing law?
Hmmmm, not that I can think off because the aproach needed there would depend heavily on the sittuation. Killing a shred happens abruptly and not always too musically. How
can this be done for nicer sonic output in performance?
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? 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? A further usability issue was revealed when I tried to use a patch
from the examples folder that required sound files. These were referred to by relative pathing, but this only works if the script is run in its own folder. It appears there is no way to programmatically specify the root folder. So how does one integrate patches like this into a miniAudicle session?
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. Thanks for your help with these very practical issues. I will be
writing an article soon on ChucK for my blog diagrammes modernes, so will incorporate any tips.
Excelent, do post a link to your blog to the list when you do. Kas.
participants (2)
-
Kassen -
robin.escalation