Re: [haskell-art] [hsc3] soundIn
hello stefan, > 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. finally applied and pushed, away longer than expected. i deleted the empty mce test and added an error case to the core 'mce' constructor, i can't see any reason to have empty mce values, and i doubt they are checked for anywhere else... really, UGen ought to be abstract and not user accessible, but that is a longer story. kind regards, rohan ___ haskell-art mailing list haskell-art@lists.lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [hsc3] soundIn
hello stefan, > 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. excellent, many thanks! i am away for a few days but will apply and push next week. 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 22.04.2008, at 01:39, Rohan Drape wrote: 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 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. soundIn+haddock.patch Description: Binary data ___ 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 > 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
