waveform~ problems

Sep 6, 2006 at 4:21pm

waveform~ problems

Hi!

Please have a look at my very simple patch. It should record 2
seconds of audio, crop it via waveform to 1 second, and then
normalize it. I use trigger to force this order on stop.
Unfortunately, the normalize doesn’t happen. The bang that should
trigger the normalisation flashes, but nothing happens. I have to
‘wait’ before normalisation works.

In the (more elaborate) patch that I’m working on, I need this to
work properly, preferably without kludges with delay objects etc.

I also have problems with writing the buffer to disk immediately
(welll, properly timed with more trigger objects) after cropping and
normalizing. The file will be empty, unless I wait for a while.

Methinks this is really dumb & simple stuff that should work
flawlessly. It doesn’t work for me. Am I crazy? Is it my system?

One more thing: On advice of Andrew B. I’ve switched overdrive off,
or else Max will crash. I don’t know if it will crash in this sample
example, but it sure crashes my original patch.

System: PBook G4 1.5 GHz/2 GB RAM/OSX.4.7/Max 4.6.1

Best,

Zip

BTW: why doesn’t the loadbang in my patch automatically start the audio?

max v2;
#N vpatcher 159 283 907 736;
#P button 187 164 15 0;
#P window setfont “Sans Serif” 9.;
#P message 281 82 14 196617 1;
#P message 75 383 14 196617 0;
#P newex 75 358 36 196617 edge~;
#P newex 75 332 51 196617 >~ 0.999;
#P newex 42 116 31 196617 t 1 b;
#P message 124 209 55 196617 size 2000;
#P newex 78 86 32 196617 sel 1;
#P message 224 187 72 196617 normalize 0.9;
#P message 337 189 30 196617 crop;
#P newex 337 163 40 196617 t b 0 i;
#P message 317 81 46 196617 set bert;
#P newex 317 47 48 196617 loadbang;
#P user waveform~ 317 224 200 74 3 9;
#W mode select;
#W mouseoutput continuous;
#W unit ms;
#W grid 1000.;
#W ticks 0;
#W labels 1;
#W vlabels 0;
#W vticks 1;
#W bpm 120. 4.;
#W frgb 33 0 0;
#W brgb 60 178 173;
#W rgb2 0 95 255;
#W rgb3 0 0 0;
#W rgb4 0 0 0;
#W rgb5 190 137 255;
#W rgb6 100 100 100;
#W rgb7 100 100 100;
#P newex 130 116 49 196617 t b 1000;
#P newex 130 87 32 196617 sel 0;
#P newex 75 306 68 196617 record~ bert;
#P user ezadc~ 16 204 60 237 0;
#P newex 124 242 93 196617 buffer~ bert 2000;
#P toggle 126 26 15 0;
#P window linecount 8;
#P comment 486 44 103 196617 record a 2 second sample in bert after 2
seconds: 1. stop 2. trim to 1 second 3. normalize 3. doesn’t happen?!;
#P window linecount 1;
#P comment 150 26 100 196617 hit me!;
#P connect 20 0 4 0;
#P connect 14 0 16 0;
#P connect 16 0 5 0;
#P connect 4 0 5 0;
#P connect 5 0 17 0;
#P connect 17 0 18 0;
#P connect 18 0 19 0;
#P connect 2 0 14 0;
#P connect 16 1 15 0;
#P connect 15 0 3 0;
#P fasten 19 0 2 0 8 398 8 24 131 24;
#P connect 2 0 6 0;
#P connect 6 0 7 0;
#P connect 7 0 21 0;
#P connect 21 0 13 0;
#P connect 9 0 20 0;
#P connect 9 0 10 0;
#P connect 13 0 8 0;
#P connect 12 0 8 0;
#P connect 10 0 8 0;
#P connect 7 1 11 0;
#P connect 11 0 12 0;
#P connect 11 1 8 2;
#P connect 11 2 8 3;
#P pop;

#27510
Sep 6, 2006 at 4:37pm

use [deferlow] to execute the normalisation (and writing) in the low-
priority queue. there’s some drawing involved, that might be the
reason it doesn’t work from the high priority level.

as for the ezdac~ not reacting to the loadbang: do you have a valid
driver selected?

/*j

On 6 Sep 2006, at 18:21, Zip Boterbloem wrote:

> Hi!
>
> Please have a look at my very simple patch. It should record 2
> seconds of audio, crop it via waveform to 1 second, and then
> normalize it. I use trigger to force this order on stop.
> Unfortunately, the normalize doesn’t happen. The bang that should
> trigger the normalisation flashes, but nothing happens. I have to
> ‘wait’ before normalisation works.
>
> In the (more elaborate) patch that I’m working on, I need this to
> work properly, preferably without kludges with delay objects etc.
>
> I also have problems with writing the buffer to disk immediately
> (welll, properly timed with more trigger objects) after cropping
> and normalizing. The file will be empty, unless I wait for a while.
>
> Methinks this is really dumb & simple stuff that should work
> flawlessly. It doesn’t work for me. Am I crazy? Is it my system?
>
> One more thing: On advice of Andrew B. I’ve switched overdrive
> off, or else Max will crash. I don’t know if it will crash in this
> sample example, but it sure crashes my original patch.
>
> System: PBook G4 1.5 GHz/2 GB RAM/OSX.4.7/Max 4.6.1
>
> Best,
>
> Zip
>
> BTW: why doesn’t the loadbang in my patch automatically start the
> audio?
>
> max v2;
> #N vpatcher 159 283 907 736;
> #P button 187 164 15 0;
> #P window setfont “Sans Serif” 9.;
> #P message 281 82 14 196617 1;
> #P message 75 383 14 196617 0;
> #P newex 75 358 36 196617 edge~;
> #P newex 75 332 51 196617 >~ 0.999;
> #P newex 42 116 31 196617 t 1 b;
> #P message 124 209 55 196617 size 2000;
> #P newex 78 86 32 196617 sel 1;
> #P message 224 187 72 196617 normalize 0.9;
> #P message 337 189 30 196617 crop;
> #P newex 337 163 40 196617 t b 0 i;
> #P message 317 81 46 196617 set bert;
> #P newex 317 47 48 196617 loadbang;
> #P user waveform~ 317 224 200 74 3 9;
> #W mode select;
> #W mouseoutput continuous;
> #W unit ms;
> #W grid 1000.;
> #W ticks 0;
> #W labels 1;
> #W vlabels 0;
> #W vticks 1;
> #W bpm 120. 4.;
> #W frgb 33 0 0;
> #W brgb 60 178 173;
> #W rgb2 0 95 255;
> #W rgb3 0 0 0;
> #W rgb4 0 0 0;
> #W rgb5 190 137 255;
> #W rgb6 100 100 100;
> #W rgb7 100 100 100;
> #P newex 130 116 49 196617 t b 1000;
> #P newex 130 87 32 196617 sel 0;
> #P newex 75 306 68 196617 record~ bert;
> #P user ezadc~ 16 204 60 237 0;
> #P newex 124 242 93 196617 buffer~ bert 2000;
> #P toggle 126 26 15 0;
> #P window linecount 8;
> #P comment 486 44 103 196617 record a 2 second sample in bert after
> 2 seconds: 1. stop 2. trim to 1 second 3. normalize 3. doesn’t
> happen?!;
> #P window linecount 1;
> #P comment 150 26 100 196617 hit me!;
> #P connect 20 0 4 0;
> #P connect 14 0 16 0;
> #P connect 16 0 5 0;
> #P connect 4 0 5 0;
> #P connect 5 0 17 0;
> #P connect 17 0 18 0;
> #P connect 18 0 19 0;
> #P connect 2 0 14 0;
> #P connect 16 1 15 0;
> #P connect 15 0 3 0;
> #P fasten 19 0 2 0 8 398 8 24 131 24;
> #P connect 2 0 6 0;
> #P connect 6 0 7 0;
> #P connect 7 0 21 0;
> #P connect 21 0 13 0;
> #P connect 9 0 20 0;
> #P connect 9 0 10 0;
> #P connect 13 0 8 0;
> #P connect 12 0 8 0;
> #P connect 10 0 8 0;
> #P connect 7 1 11 0;
> #P connect 11 0 12 0;
> #P connect 11 1 8 2;
> #P connect 11 2 8 3;
> #P pop;
>

#83293
Sep 6, 2006 at 5:08pm

On 6 sept. 06, at 18:37, /*j wrote:

> as for the ezdac~ not reacting to the loadbang: do you have a valid
> driver selected?

For that matter, it’s another problem wich is you can’t start the dsp
chain on strartup. You’ll need a delay (even [delay 0] should work).

Best,
ej

#83294
Sep 6, 2006 at 11:28pm

#83295
Sep 8, 2006 at 10:50am

Zip Boterbloem wrote:
> Unfortunately, the normalize doesn’t happen. The bang that should
> trigger the normalisation flashes, but nothing happens. I have to ‘wait’
> before normalisation works.

Any destructive edit (crop and normalize fall into that cathegory) would
need a complet copying of the whole buffer. definitely somthing which
might not be ready in the same scheduler thread. It has to be done in
low priority…
Thatswhy deferlow works, it will be executed after its ready and would
not try to do it before the task is finished…

> In the (more elaborate) patch that I’m working on, I need this to work
> properly, preferably without kludges with delay objects etc.

The deferlow/delay 0 will be the minimum delay required…

> I also have problems with writing the buffer to disk immediately (welll,
> properly timed with more trigger objects) after cropping and
> normalizing. The file will be empty, unless I wait for a while.

Same reason, same solution…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#83296
Sep 8, 2006 at 11:21am

Hi Stefan,

Op 8-sep-2006, om 12:50 heeft Stefan Tiedje het volgende geschreven:

> Zip Boterbloem wrote:
>> Unfortunately, the normalize doesn’t happen. The bang that should
>> trigger the normalisation flashes, but nothing happens. I have to
>> ‘wait’ before normalisation works.
>
> Any destructive edit (crop and normalize fall into that cathegory)
> would need a complet copying of the whole buffer. definitely
> somthing which might not be ready in the same scheduler thread. It
> has to be done in low priority…
> Thatswhy deferlow works, it will be executed after its ready and
> would not try to do it before the task is finished…

Ah. I see. But if I deferlow some messages, will other messages (not
deferlowed) not come early? E.g. what to deferlow and what not? BTW,
I already switched off overdrive mode.

>
>> In the (more elaborate) patch that I’m working on, I need this to
>> work properly, preferably without kludges with delay objects etc.
>
> The deferlow/delay 0 will be the minimum delay required…
>
>> I also have problems with writing the buffer to disk immediately
>> (welll, properly timed with more trigger objects) after cropping
>> and normalizing. The file will be empty, unless I wait for a while.
>
> Same reason, same solution…

Thansk for your insights. Much appreciated!

Best,

Zip

#83297
Sep 11, 2006 at 10:17pm

Zip Boterbloem wrote:
> Ah. I see. But if I deferlow some messages, will other messages (not
> deferlowed) not come early? E.g. what to deferlow and what not? BTW, I
> already switched off overdrive mode.

Yes, of course, as the deferlow.help demonstrates. But you can get back
the order if you deferlow the other messages as well… best use a
trigger just behind the deferlow to get the correct order…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#83298

You must be logged in to reply to this topic.