Cheng Chien-Wen

I am trying to make a patch that can report the number of pitches within the latest 1 sec or fixed duration. I made a little patch with bucket, expr, counter, metro, etc, but it does not seem to be precise and efficient enough. Can any one give me some suggestions about it ?

Hi, 
I am trying to make a patch that can report the number of pitches within the latest 1 sec or fixed duration. I made a little patch with bucket, expr, counter, metro, etc, but it does not seem to be precise and efficient enough. Can any one give me some suggestions about it ?

windowed-pitch-density

Here's a modified version of your patch. I can't vouch that it will be any more precise, since I believe what goes on inside fiddle~ determines the accuracy more than anything else. However, it may be more efficient.

Collecting the pitches into a list relies on a bit of a hack with the Lcatch object. I've set the reporting interval to some arbitrarily large number (10000 ms) and the length list to its maximum (256 members). This lets us be relatively sure the output is the result of the metro bangs and not Lcatch timing out or reaching its maximum list length. Does anyone have a more elegant solution for this?

I'd recommend replacing fiddle~ with some simpler data input, such as a notein object, to test that the patch is really producing the values you expect. Then you can concentrate on tweaking fiddle~ to get more accurate results.

Here's a modified version of your patch. I can't vouch that it will be any more precise, since I believe what goes on inside fiddle~ determines the accuracy more than anything else. However, it may be more efficient. 

I'd recommend replacing fiddle~ with some simpler data input, such as a notein object, to test that the patch is really producing the values you expect. Then you can concentrate on tweaking fiddle~ to get more accurate results. 

My professor just provided me a very smart way to do this.

I only needs pipe object to deduct the number of the data previouisly collected after e.g, 1000 ms.

In other words, accum object counts the numbers of pitches and pipe keeps deducting one from the total number after a specified time. In this way, I can always get the numbers of pitches in the latest 1 sec.

There is no need to do a complicated counting like my previous patch. That's really a surprising solution.

My professor just provided me a very smart way to do this.
I only needs pipe object to deduct the number of the data previouisly collected after e.g, 1000 ms.

There is no need to do a complicated counting like my previous patch. That's really a surprising solution.


I'm putting together a proposal for a sound design to accompany a very

dispersed site specific project that will be presented at various locations

around an old industrial rail yard complex.

There will be five individual performers installed at different locations

around the venue, and they each require their own sound track: we would like

the sound elements to be able to converge at key moments, and I'll be

exploring how to resonate different parts of the complex with sub bass

Rather than purchasing 2 very expensive 16 I/O units and running thousands

of meters of cabling around the complex from a single computer, I thought I

could network a collection of basic PC's to play sound files and simple

synth patches, with each PC being connected to local speakers, thereby

substituting long and costly speaker cable runs, with five very long

Question: does anyone have some experience to share about the effectiveness

of networked PC's for this kind of synchronised sound dispersion?

I imagined that I would be building a series of soundfile players and signal

mixers for each of the five PC's that would be controlled from a central PC

The central PC (or Mac G4) will be transmitting basic 'start/stop', 'select

file', 'control channel gain' instructions.

It all seems very straight forward, but I just wanted to check around for

any latency issues with this kind of networking. How about wireless

I'm putting together a proposal for a sound design to accompany a very
dispersed site specific project that will be presented at various locations
around an old industrial rail yard complex.

There will be five individual performers installed at different locations
around the venue, and they each require their own sound track: we would like
the sound elements to be able to converge at key moments, and I'll be
exploring how to resonate different parts of the complex with sub bass
frequencies.

Rather than purchasing 2 very expensive 16 I/O units and running thousands
of meters of cabling around the complex from a single computer, I thought I
could network a collection of basic PC's to play sound files and simple
synth patches, with each PC being connected to local speakers, thereby
substituting long and costly speaker cable runs, with five very long
Ethernet cables.

Question: does anyone have some experience to share about the effectiveness
of networked PC's for this kind of synchronised sound dispersion?

I imagined that I would be building a series of soundfile players and signal
mixers for each of the five PC's that would be controlled from a central PC
using OpenSoundControl.

The central PC (or Mac G4) will be transmitting basic 'start/stop', 'select
file', 'control channel gain' instructions.

It all seems very straight forward, but I just wanted to check around for
any latency issues with this kind of networking. How about wireless
networking (sound like trouble to me)?

george@georgekhut.com
http://www.georgekhut.com


On 25 Oct 2006, at 01:11, George (Poonkhin) Khut wrote:

> It all seems very straight forward, but I just wanted to check 

> any latency issues with this kind of networking.

There will be some latency, but I've never noticed any response 

problems using OSC. What accuracy of synchronisation do you need?

Absolutely. Don't go wireless unless you have no choice.

nick rothwell -- composition, systems, performance -- 

> It all seems very straight forward, but I just wanted to check  
> around for
> any latency issues with this kind of networking.

There will be some latency, but I've never noticed any response  
problems using OSC. What accuracy of synchronisation do you need?

> How about wireless
> networking (sound like trouble to me)?

   nick rothwell -- composition, systems, performance -- http:// 
www.cassiel.com


>> It all seems very straight forward, but I just wanted to check

>> any latency issues with this kind of networking.

> There will be some latency, but I've never noticed any response

> problems using OSC. What accuracy of synchronisation do you need?

Only to a few hundred milliseconds i.e. Half a second would be not so good,

but anything below that would be acceptable.

I'll stay away from the wireless for a while more!

>> It all seems very straight forward, but I just wanted to check
>> around for
>> any latency issues with this kind of networking.
>
> There will be some latency, but I've never noticed any response
> problems using OSC. What accuracy of synchronisation do you need?
Only to a few hundred milliseconds i.e. Half a second would be not so good,
but anything below that would be acceptable.

George Poonkhin Khut
4/131 Carrington Road
RANDWICK NSW 2031
Mob 0417 566 425
Home 02 9398 9229

On 25 Oct 2006, at 12:08, George (Poonkhin) Khut wrote:

> Only to a few hundred milliseconds i.e. Half a second would be not 

> but anything below that would be acceptable.

If you're using sfplay~, then be SURE to preload the cues for the 

files you want to play; don't try to call "play" on them in real 

time. (This is a mistake I see lots of people make.)

> Only to a few hundred milliseconds i.e. Half a second would be not  
> so good,
> but anything below that would be acceptable.

If you're using sfplay~, then be SURE to preload the cues for the  
files you want to play; don't try to call "play" on them in real  
time. (This is a mistake I see lots of people make.)

windowed pitch density ?