On 22.04.2008, at 01:39, Rohan Drape wrote:
great, thanks, mce is what i was looking for. am i correct inthere is a start of a sketch of the mce rules at: http://slavepianos.org/rd/sw/hsc3/Help/hsc3.help.lhs
thanks, lots of interesting stuff in there!
assuming that in' 2 AR 0 compiles to a single In ugen, while soundIn [0, 1] references two? what i meant was making the first argument to in' available as an argument to soundIn. reading consecutive input buses is a fairly common scenario ...yes, correct, i've not optimised this to group conseuctive inputs, i've never had enough input channels to notice the inefficiency, but it can moderately easily be done, & i'd happily take a patch!
i've attached a patch; there's a slight runtime overhead of course for detecting consecutive bus indices ... the test for an empty input MCE is also slightly ugly, probably there's a better way.
if all inputs are consecutive we can just use in' directly? are you thinking of soundInN defined as:soundInN :: Int -> UGen -> UGen soundInN x n = in' x AR (numOutputBuses + n)so that, ie. soundInN 3 (mce2 0 2) reads channel 2 twice? perhaps it's just as clear to write soundIn (mce [0,1,2,2,3,4]) or even soundIn (mce ([0..2]++[2..4]) )?
yes, you're right, the semantics would be a bit confusing. <sk>
soundIn+haddock.patch
Description: Binary data
_______________________________________________ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
