Re: [haskell-art] [hsc3] soundIn
> great, thanks, mce is what i was looking for. am i correct in > 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 actually, i don't think this is written down anywhere, but for unit generators that in sclang take a psuedo-input to set the number of channels in hsc3 that value has been pulled out before the rate specifier (if there is one) and made into an Int, so one can write: > let in2 = in' 2 in in2 AR 2 ... rd ___ haskell-art mailing list haskell-art@lists.lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [hsc3] soundIn
> great, thanks, mce is what i was looking for. am i correct in there is a start of a sketch of the mce rules at: http://slavepianos.org/rd/sw/hsc3/Help/hsc3.help.lhs (ie. in the hsc3 sources, notes from never completed sc3 book effort) > 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! 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]) )? regards, rohan ___ haskell-art mailing list haskell-art@lists.lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [hsc3] soundIn
On 21.04.2008, at 16:35, Rohan Drape wrote: >> >> is there a particular reason soundIn hides the number of channels >> being read? maybe a variation (soundInN?) could be added? > > i'm not sure i understand the question, can you perhaps elaborate? > > the number of channels being read is the degree (number of output > ports) of the input, which selects which channels to read, zero > indexed. > > soundIn :: UGen -> UGen > soundIn n = in' 1 AR (numOutputBuses + n) great, thanks, mce is what i was looking for. am i correct in 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 ... thanks, ___ haskell-art mailing list haskell-art@lists.lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [hsc3] soundIn
hello stefan, > is there a particular reason soundIn hides the number of channels > being read? maybe a variation (soundInN?) could be added? i'm not sure i understand the question, can you perhaps elaborate? the number of channels being read is the degree (number of output ports) of the input, which selects which channels to read, zero indexed. soundIn :: UGen -> UGen soundIn n = in' 1 AR (numOutputBuses + n) you can query the degree of a unit generator with mceDegree, or somewhat more reliably with length . mceChannels. > [ mceDegree (soundIn (mce [0,2..14])) > , (length . mceChannels) (soundIn 3) ] => [8,1] regards, rohan ps. we could define this as a 'proper' interface ugenDegree :: UGen -> Int ugenDegree = length . mceChannels but i've never had call for it, what is the usage scenario? ___ haskell-art mailing list haskell-art@lists.lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] [hsc3] soundIn
hi rohan, all, is there a particular reason soundIn hides the number of channels being read? maybe a variation (soundInN?) could be added? ___ haskell-art mailing list haskell-art@lists.lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
