windowed pitch density ?

Oct 19, 2006 at 8:08am

windowed pitch density ?

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 ?

Thanks.

My patch is as follows:

max v2;
#N vpatcher 440 114 1040 514;
#P user ezdac~ 354 245 398 278 0;
#P user gain~ 353 102 24 100 158 0 1.071519 7.94321 10.;
#P toggle 114 21 15 0;
#P window setfont “Sans Serif” 9.;
#P message 80 18 28 9109513 open;
#N sfplay~ 1 120960 0 ;
#P newobj 107 40 40 9109513 sfplay~;
#P newex 108 66 53 9109513 fiddle~;
#P button 215 198 15 0;
#P button 102 171 15 0;
#P message 248 216 18 9109513 r2l;
#P message 159 116 14 9109513 1;
#P newex 159 93 45 9109513 loadbang;
#P number 102 313 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 102 289 199 9109513 expr $i1 + $i2 +$i3 + $i4 + $i5 + $i6 + $i7 + $i8;
#P newex 138 254 105 9109513 bucket 8;
#P toggle 159 138 15 0;
#P number 138 231 35 9 0 0 0 139 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 163 179 19 9109513 t 0;
#P newex 108 120 41 9109513 split 0 0;
#P newex 162 158 50 9109513 metro 200;
#P newex 139 159 19 9109513 t b;
#N counter;
#X flags 0 0;
#P newobj 139 207 66 9109513 counter;
#P connect 3 1 13 0;
#P connect 13 0 8 0;
#P connect 7 0 8 0;
#P connect 8 0 9 0;
#P connect 18 0 16 0;
#P connect 17 0 16 0;
#P connect 16 0 15 0;
#P connect 15 0 3 0;
#P connect 7 1 8 1;
#P connect 0 0 5 0;
#P connect 5 0 7 0;
#P connect 12 0 7 0;
#P connect 3 1 1 0;
#P connect 1 0 0 0;
#P connect 7 2 8 2;
#P connect 10 0 11 0;
#P connect 11 0 6 0;
#P connect 6 0 2 0;
#P connect 2 0 4 0;
#P connect 4 0 0 2;
#P connect 7 3 8 3;
#P connect 7 4 8 4;
#P connect 4 0 14 0;
#P connect 7 5 8 5;
#P connect 10 0 12 0;
#P connect 7 6 8 6;
#P connect 7 7 8 7;
#P connect 16 0 19 0;
#P connect 19 0 20 0;
#P connect 19 0 20 1;
#P pop;

#28254
Oct 20, 2006 at 3:12pm

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.

Holland

max v2;
#N vpatcher 440 114 1087 573;
#P origin -18 -3;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 0 314 35 196617 sel 0.;
#P number 25 387 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 25 366 34 196617 zl len;
#P message 79 390 239 196617 56.990898;
#P newex 79 367 62 196617 prepend set;
#P newex 25 340 93 196617 Lcatch 10000 256;
#P number 228 139 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P toggle 258 28 15 0;
#P newex 241 48 27 196617 1;
#P user ezdac~ 372 248 416 281 0;
#P user gain~ 371 105 24 100 158 0 1.071519 7.94321 10.;
#P toggle 132 24 15 0;
#P message 98 21 28 196617 open;
#N sfplay~ 1 120960 0 ;
#P newobj 125 43 40 196617 sfplay~;
#P newex 126 69 53 196617 fiddle~;
#P button 233 201 15 0;
#P button 120 174 15 0;
#P window linecount 2;
#P message 266 219 18 196617 r2l;
#P window linecount 1;
#P message 177 119 14 196617 1;
#P newex 177 96 45 196617 loadbang;
#P number 120 316 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 120 292 235 196617 expr $i1 + $i2 +$i3 + $i4 + $i5 + $i6 + $i7 + $i8;
#P newex 156 257 105 196617 bucket 8;
#P toggle 177 141 15 0;
#P number 156 234 35 9 0 0 0 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P newex 181 182 19 196617 t 0;
#P newex 126 123 48 196617 split 0 0;
#P newex 180 161 58 196617 metro 200;
#P newex 157 162 19 196617 t b;
#N counter;
#X flags 0 0;
#P newobj 157 210 66 196617 counter;
#P connect 15 0 29 0;
#P connect 29 1 24 0;
#P connect 2 0 24 0;
#P connect 24 0 27 0;
#P connect 27 0 28 0;
#P connect 24 0 25 0;
#P connect 25 0 26 0;
#P connect 3 1 13 0;
#P connect 7 0 8 0;
#P connect 13 0 8 0;
#P connect 8 0 9 0;
#P connect 21 0 16 0;
#P connect 17 0 16 0;
#P connect 18 0 16 0;
#P connect 16 0 15 0;
#P connect 15 0 3 0;
#P connect 7 1 8 1;
#P connect 0 0 5 0;
#P connect 12 0 7 0;
#P connect 5 0 7 0;
#P connect 3 1 1 0;
#P connect 1 0 0 0;
#P connect 10 0 11 0;
#P connect 11 0 6 0;
#P connect 6 0 2 0;
#P connect 2 0 4 0;
#P connect 7 2 8 2;
#P connect 4 0 0 2;
#P connect 7 3 8 3;
#P connect 23 0 2 1;
#P connect 4 0 14 0;
#P fasten 16 1 21 0 157 63 246 43;
#P connect 7 4 8 4;
#P connect 22 0 21 1;
#P connect 10 0 12 0;
#P connect 7 5 8 5;
#P connect 7 6 8 6;
#P connect 7 7 8 7;
#P connect 16 0 19 0;
#P connect 19 0 20 0;
#P connect 19 0 20 1;
#P pop;

#86592
Oct 22, 2006 at 8:20am

Thanks for the help.

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.

#86593
Oct 25, 2006 at 12:10am

Hi everyone

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)?

Cheers

George Khut

george@georgekhut.com

http://www.georgekhut.com

#86594
Oct 25, 2006 at 9:44am

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

> 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)?

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

– N.

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

#86595
Oct 25, 2006 at 11:06am

>> 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.

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

Thanks for your response

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

george@georgekhut.com

http://www.georgekhut.com

#86596
Oct 25, 2006 at 5:31pm

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
> 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.)

– N.

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

#86597
Oct 26, 2006 at 11:23am

#86598

You must be logged in to reply to this topic.