headers
James Harkins | 1 Jan 2007 22:34
Picon

[approve] variable range for Pwhite

May I suggest the following enhancement for Pwhite? It would be nice to have the random range determined by patterns, rather than being fixed.

+ Pwhite {
embedInStream { arg inval;
var loStream = lo.asStream,
hiStream = hi.asStream;
length.do({
inval = rrand(loStream.next(inval) ?? { ^inval },
hiStream.next(inval) ?? { ^inval })
.yield;
});
^inval;
}
}

OK to commit?

hjh


: H. James Harkins

: jamshark70-n2XjBy9Frl0FLkkUnhLBSV6hYfS7NtTn@public.gmane.org

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:


"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman


_______________________________________________
sc-dev mailing list
sc-dev@...
http://www.create.ucsb.edu/mailman/listinfo/sc-dev
Permalink | Reply | 16 comments |
headers
Julian Rohrhuber | 1 Jan 2007 22:54
Picon
Favicon

Re: [approve] variable range for Pwhite

>May I suggest the following enhancement for Pwhite? It would be nice 
>to have the random range determined by patterns, rather than being 
>fixed.
>
>+ Pwhite {
>	embedInStream { arg inval;
>		var	loStream = lo.asStream,
>			hiStream = hi.asStream;
>		length.do({
>			inval = rrand(loStream.next(inval) ?? { ^inval },
>				hiStream.next(inval) ?? { ^inval })
>				.yield;
>		});
>		^inval;
>	}
>}
>
>OK to commit?

yes, I think it is a good idea. Maybe you can do the same for Pbrown?
--

-- 

.
Permalink | Reply | 15 comments |
headers
ronald kuivila | 1 Jan 2007 23:02

Re: [approve] variable range for Pwhite

Hi Julian and James,

  Perhaps we should get rid of as many static arguments in patterns  
as possible
(i.e., most arguments should be treated as streams)....
It would make everything much more consistent. Is that too extreme?

  In the case of Pwhite, the counter argument is that you can use  
rrand with patterns to get the same result as Pwhite, but
that seems too technical to me.)

RJK

On Jan 1, 2007, at 4:54 PM, Julian Rohrhuber wrote:

>> May I suggest the following enhancement for Pwhite? It would be  
>> nice to have the random range determined by patterns, rather than  
>> being fixed.
>>
>> + Pwhite {
>> 	embedInStream { arg inval;
>> 		var	loStream = lo.asStream,
>> 			hiStream = hi.asStream;
>> 		length.do({
>> 			inval = rrand(loStream.next(inval) ?? { ^inval },
>> 				hiStream.next(inval) ?? { ^inval })
>> 				.yield;
>> 		});
>> 		^inval;
>> 	}
>> }
>>
>> OK to commit?
>
> yes, I think it is a good idea. Maybe you can do the same for Pbrown?
> -- 
>
>
>
>
>
> .
> _______________________________________________
> sc-dev mailing list
> sc-dev@...
> http://www.create.ucsb.edu/mailman/listinfo/sc-dev
Permalink | Reply | 14 comments |
headers
Julian Rohrhuber | 1 Jan 2007 23:41
Picon
Favicon

Re: [approve] variable range for Pwhite

>Hi Julian and James,
>
>  Perhaps we should get rid of as many static arguments in patterns as possible
>(i.e., most arguments should be treated as streams)....
>It would make everything much more consistent. Is that too extreme?

I would appreciate it. It has been on my list for a long time.

There are mainly two cases: next is called on the argument stream 
each time, or once every time the first stream has ended. This will 
have to be made clearer in the helpfiles too, maybe.

>
>  In the case of Pwhite, the counter argument is that you can use 
>rrand with patterns to get the same result as Pwhite, but
>that seems too technical to me.)

The counter argument is that it will change the behaviour of streams 
in the arguments and thus may break code.

>
>RJK
>
>On Jan 1, 2007, at 4:54 PM, Julian Rohrhuber wrote:
>
>>>May I suggest the following enhancement for Pwhite? It would be 
>>>nice to have the random range determined by patterns, rather than 
>>>being fixed.
>>>
>>>+ Pwhite {
>>>	embedInStream { arg inval;
>>>		var	loStream = lo.asStream,
>>>			hiStream = hi.asStream;
>>>		length.do({
>>>			inval = rrand(loStream.next(inval) ?? { ^inval },
>>>				hiStream.next(inval) ?? { ^inval })
>>>				.yield;
>>>		});
>>>		^inval;
>>>	}
>>>}
>>>
>>>OK to commit?
>>
>>yes, I think it is a good idea. Maybe you can do the same for Pbrown?
>>--
>>
>>
>>
>>
>>
>>.
>>_______________________________________________
>>sc-dev mailing list
>>sc-dev@...
>>http://www.create.ucsb.edu/mailman/listinfo/sc-dev
>
>_______________________________________________
>sc-dev mailing list
>sc-dev@...
>http://www.create.ucsb.edu/mailman/listinfo/sc-dev

--

-- 

.
Permalink | Reply | 13 comments |
headers
Julian Rohrhuber | 1 Jan 2007 23:55
Picon
Favicon

Re: [approve] variable range for Pwhite

>>Hi Julian and James,
>>
>>  Perhaps we should get rid of as many static arguments in patterns 
>>as possible
>>(i.e., most arguments should be treated as streams)....
>>It would make everything much more consistent. Is that too extreme?
>
>I would appreciate it. It has been on my list for a long time.
>
>There are mainly two cases: next is called on the argument stream 
>each time, or once every time the first stream has ended. This will 
>have to be made clearer in the helpfiles too, maybe.
>
>>
>>  In the case of Pwhite, the counter argument is that you can use 
>>rrand with patterns to get the same result as Pwhite, but
>>that seems too technical to me.)
>
>The counter argument is that it will change the behaviour of streams 
>in the arguments and thus may break code.
>

actually maybe we should call .value before calling .asStream - then 
it would still work both ways. Again, this may cause confusion in 
some cases.
--

-- 

.
Permalink | Reply | 11 comments |
headers
ronald kuivila | 2 Jan 2007 03:47

Re: [approve] variable range for Pwhite

>

Hi Julian,

   Why call value?

RJK

> actually maybe we should call .value before calling .asStream -  
> then it would still work both ways. Again, this may cause confusion  
> in some cases.
> -- 
>
>
>
>
>
> .
> _______________________________________________
> sc-dev mailing list
> sc-dev@...
> http://www.create.ucsb.edu/mailman/listinfo/sc-dev
Permalink | Reply | 10 comments |
headers
James Harkins | 2 Jan 2007 04:27
Picon

Re: [approve] variable range for Pwhite

On Jan 1, 2007, at 5:41 PM, Julian Rohrhuber wrote:

 Perhaps we should get rid of as many static arguments in patterns as possible
(i.e., most arguments should be treated as streams)....
It would make everything much more consistent. Is that too extreme?

I would appreciate it. It has been on my list for a long time.


While we're considering inconsistencies in pattern implementations, we should also correct all the instances where next is called on the child stream without passing in the input value.


I have a list of next calls to review, some of which are probably correct but I know a bunch of them are oversights. I think it's longer than 40 KB, though, so I can't attach it to the e-mail.


hjh


: H. James Harkins

: jamshark70-n2XjBy9Frl0FLkkUnhLBSV6hYfS7NtTn@public.gmane.org

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:


"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman


_______________________________________________
sc-dev mailing list
sc-dev@...
http://www.create.ucsb.edu/mailman/listinfo/sc-dev
Permalink | Reply | 0 comments |
headers
Sciss | 2 Jan 2007 12:25
Picon
Gravatar

Unifying scsynth output device list display

hi,

i just recognize that the -H option for scsynth seems to work now for  
the windows version, too. there was this thread recently about using  
Pipe to determine the available devices. unfortunately, the windows  
version uses a different text formatting for the output devices. they  
show up like this:

Device options:
   - MME : Microsoft Soundmapper - Input   (device #0 with 2 ins 0 outs)
[...]
   - ASIO : Asio Hammerfall DSP   (device #4 with 26 ins 26 outs)

it would be cool to have the same format across platforms, so one can  
use the same parsing code everywhere. i don't care whether that is  
the mac format ("Number of Devices: 4\n   0 : "Built-in Microphone""  
etc.) or the PC format. however, the extra info on # of inputs and  
outputs on the PC seems to be really cool. i would want to use that  
for automatic setup in eisenkraut for example, where at the moment i  
have no clue as how to determine the # of hardware inputs and outputs.

i don't have a linux machine at hand now, but will check soon how it  
looks there.

just a suggestion. ciao, -sciss-
Permalink | Reply | 3 comments |
headers
ronald kuivila | 2 Jan 2007 13:51

Re: Unifying scsynth output device list display

Hi all,

Would there be objections to making the print out an SC parsable  
string, perhaps
as key/value pairs:

"[
[
	name: \MME
	comment: "Microsoft Soundmapper Input"
	deviceNumber: 0,
	ins: 2,
	outs: 0
],...
]

RJK

On Jan 2, 2007, at 6:25 AM, Sciss wrote:

> hi,
>
> i just recognize that the -H option for scsynth seems to work now  
> for the windows version, too. there was this thread recently about  
> using Pipe to determine the available devices. unfortunately, the  
> windows version uses a different text formatting for the output  
> devices. they show up like this:
>
> Device options:
>   - MME : Microsoft Soundmapper - Input   (device #0 with 2 ins 0  
> outs)
> [...]
>   - ASIO : Asio Hammerfall DSP   (device #4 with 26 ins 26 outs)
>
>
> it would be cool to have the same format across platforms, so one  
> can use the same parsing code everywhere. i don't care whether that  
> is the mac format ("Number of Devices: 4\n   0 : "Built-in  
> Microphone"" etc.) or the PC format. however, the extra info on #  
> of inputs and outputs on the PC seems to be really cool. i would  
> want to use that for automatic setup in eisenkraut for example,  
> where at the moment i have no clue as how to determine the # of  
> hardware inputs and outputs.
>
> i don't have a linux machine at hand now, but will check soon how  
> it looks there.
>
> just a suggestion. ciao, -sciss-
>
> _______________________________________________
> sc-dev mailing list
> sc-dev@...
> http://www.create.ucsb.edu/mailman/listinfo/sc-dev
Permalink | Reply | 2 comments |
headers
Julian Rohrhuber | 2 Jan 2007 13:58
Picon
Favicon

Re: [approve] variable range for Pwhite

>Hi Julian,
>
>   Why call value?
>

if you pass a function (or stream), it would be called everytime the 
pattern is embedded in a stream (as it is now) and not at every step. 
If you pass a pattern, it would create a stream that is called every 
time:

Pseq([1, 2, 3]).value.asStream.nextN(8)
{ rrand(1, 6) }.value.asStream.nextN(8)

>RJK
>
>>actually maybe we should call .value before calling .asStream - 
>>then it would still work both ways. Again, this may cause confusion 
>>in some cases.
>>--
>>
>>
>>
>>
>>
>>.
>>_______________________________________________
>>sc-dev mailing list
>>sc-dev@...
>>http://www.create.ucsb.edu/mailman/listinfo/sc-dev
>
>_______________________________________________
>sc-dev mailing list
>sc-dev@...
>http://www.create.ucsb.edu/mailman/listinfo/sc-dev

--

-- 

.
Permalink | Reply | 9 comments |

Gmane