m0dit

Using a [1ms] delay; how reasonable is that? What can i use it for?

Example, When using [sfrecord~] you have to;

Now assuming i am automating all of that what are the reasonable delay values i should setup?

-BANG-| > [delay 100?] > set toggle ON (record)

-----------| > [delay 101?] > startloop (play)

I guess it matters on the machine processor? system load? what should be reasonable minimum values?

Also in this SFrecord example i am Normalizing a file and applying a negative gain right after.(using mxj buf.Op)

Is [1ms] delay between normalization and gain reduction sufficient?

Is it a matter of, aslong as the "normalize" message is received, and the "gain" message follows, both commands will be executed regardless of the processor hangup/system load?

Using a [1ms] delay; how reasonable is that? What can i use it for?
Example, When using [sfrecord~] you have to;
1. set/create a filename to save to
2. set the record toggle ON
3. feed the signal you want to record
Now assuming i am automating all of that what are the reasonable delay values i should setup?
-----------| > createFile/name >
-BANG-| > [delay 100?] > set toggle ON (record)
-----------| > [delay 101?] > startloop (play)
I guess it matters on the machine processor? system load? what should be reasonable minimum values?

Also in this SFrecord example i am Normalizing a file and applying a negative gain right after.(using mxj buf.Op)
Is [1ms] delay between normalization and gain reduction sufficient?
Is it a matter of, aslong as the "normalize" message is received, and the "gain" message follows, both commands will be executed regardless of the processor hangup/system load?

delay-what-are-the-rules-basic-principles

Using deferlow is more appropriate in most of the cases you mention, I believe.

Hey I didn't know about deferlow, sounds very handy!

I guess you can also check the trigger [t ] object and [pipe] for more flexibility.

Hey I didn't know about deferlow, sounds very handy! 

I guess you can also check the trigger [t ] object and [pipe] for more flexibility.


errm ... in most cases the right order of messages is all you need.

sending "write sound.aif, start" as two consecutive messages to sfplay~will it make write the file, and queue the start message internally until the file creation is finished.

errm ... in most cases the right order of messages is all you need. 

sending "write sound.aif, start" as two  consecutive messages to sfplay~will it make write the file, and queue the start message internally until the file creation is finished.

Yes, the order of messages is so important, i had all forgotten about it. (still noobing)

Yes, the order of messages is so important, i had all forgotten about it. (still noobing)
Thanks for the [deferlow], cool object.


[delay] what are the rules / basic principles?