bloc counter with reset

[23fx23]

sorry a new one

would be handy for few things i got in mind...
im always after this kind of clock i still couldn't figure how to realize, most time related items have ms presision.

or there must be a way to get this already master senso?

edit: i think i found a solution, (sample time in ms X a nb of step, trying to have an integer lengh in ms as result, then a 2 point ramp curve of that lengh loop to output step values, don't know if clear, anyway..that uses lot's of cpu..im sure usine as a much easier/cpu friendly mehod..

[bsork]

You can use one of the counter patches, with eg Time(ms) through a HasChanged as a trigger for the counter.

[23fx23]

yup in fact it doesnot uses that much cpu, i was getting 10 percent cpu because I was waching the console!, when unclick tha wire its 0,20 !!! but i got dropouts arf..

ive tried the technique you mentioned bsork, pb was that i had drift because don't remember if ms was not precise enough in my calculs , or i had doubt that "has changed" modules needs 2 bloc , 1 for 0 to 1 has changed?, (or i may be totally wrong! tell me), don't remember how but i failed, will retry. thanks,

edit retried, funny i think I had tried with "precise ms" was generating slower pulses than "time ms". seems still a bit slow to be really bloc , maybe that 0-1 of the has changed? have to check, maybe it's ok in fact, thanks bsork

re edit hehe comparing the two techniques it seems yes, has changed/counter uses 2blocs, the time to generate all pulse is two times longer than the ramp, im happy to elucidate this wondering i had? so, back to my quest, will find a way!

[23fx23]

ok simple round after the ramp and no more dropouts, seems i got my bloc counter coool !!

[bsork]

Maybe a suggestion for an extra module? With a reset input and a counter output?

A script would overcome the problems. Here are two versions (not tested, just wrote them and need to go to bed ):

For V4:

Code: Select all

VAR reset, counter : tParameter;
VAR count : Integer;

PROCEDURE Init;
BEGIN
   reset := CreateParam('reset', ptButton);
   SetIsOutput(reset, FALSE);
   counter := CreateParam('counter', ptDataField);
   SetIsInput(counter, FALSE);
END;

// main
BEGIN
   IF (GetValue(reset) = 1) THEN BEGIN
      SetValue(reset, 0);
      count := 0;
   END
   ELSE BEGIN
      count := count + 1;
   END;
   SetValue(counter, count);
END.

For V5:

Code: Select all

VAR reset, counter : tParameter;
VAR count : Integer;

PROCEDURE Init;
BEGIN
   reset := CreateParam('reset', ptButton);
   SetIsOutput(reset, FALSE);
   counter := CreateParam('counter', ptDataField);
   SetIsInput(counter, FALSE);
END;

PROCEDURE Callback(n : Integer);
BEGIN
   count := 0;
END;

PROCEDURE Process;
BEGIN
   SetValue(counter, count);
   count := count + 1;
END;

[edit:]Added missing BEGINs

[23fx23]

you 're a rocking master bsork ! thanks of lot for taking that time!!!

gonna test it right away! that's seems so simple "count + 1" !
script my next do do 2010 list

[23fx23]

seems to work great ! just added a begin (v4) after procedure init. that rocks !!!!!! and stong clocky perfect, 0percent cpu! thanks again you made my day once again master bsork!
a so clear and simple example of script power over patching that really make me wanna investigate!

seems totally stupid but my first application try was to excract at each bloc next subarray of blocsize inside a bigger array contening a sine wavform
and it seems i had an audio sine out, bit aliased but working, compressing the array by 0,5 bring out the octave!
seems complex for semitones however, but opening pure usine synthesis ideas..Ive been amazed to discover the ramp module could act as a sawtooth oscillator already.

[amiga909]

the bloc counter problem tangles a bit my question in the 'patching' subforum.
can anybody explain me in easy words the relation between blocksize, real time (in ms) and midi time (midi pulses (ppq))?

thanks.

[bsork]

Block size is the size of the "chunks" of samples treated within a block; typically 64 or 128.
Real time is derived (I suppose) from the PC's clock.

Change in time between each block execution/Block duration in milliseconds: (1000 / sample_rate) / block_size
With a sample rate of 44100 and a block size of 128 that gives a block duration of ~2.9 ms.


PPQ/Midi Clock as such has nothing to do with block size or duration: It's a "metronome" sent 24 times per quarternote, or 6 per 16th-note, ie one clock message per 64th triplet note.

Time in milliseconds between each clock message: (60000 / BPM) / 24. At a BPM of 120 that gives ~20.8 ms.

[woodslanding]

sounds like that 20.8 ms could be up to 1 blocsize longer, depending on how the two clocks line up, correct? I assume no midi message is going to be processed in the middle of a bloc.....

[23fx23]

i think yes, that's working like this. bloc is the smallest usine precision clock, exept for audio where each bloc is an array of block size. ie at 128samples 8x2,9 is avevarge 23,2 not 20,8 that's why it seems hard to have strong clock with midi with a large bloc size. maybe midi clock in /out would be more accurate via usine interface, not patch?

[amiga909]

thanks a lot for ur exact explanation, bsork
always good if things seem so simple afterwards - though i feel stupid..

one addition: 24 ppq is the midi clock standard. however, most sequencers have a multiple of 24 ppq, thus allowing finer resolution than 64th triplet notes. standard nowadays is, i guess, 768 ppq - thus allowing 1/3072th notes. btw, the akai MPC has 960 ppq, and sometimes i heard this to be a reason why a MPC is 'tighter' than software.
however, 768 ppq result (at 120 bpm) in smaller intervals that can be handled with a normal duration of 2.9ms.

if i calculate correctly (with given max bpm, max buffer size) 1/32 resolutions should be a safe design constraint for the script engine.
still, i rather think i should try to incorporate seqswitch modules - as its done in the 'send midi clock' patch.

[23fx23]

yup thanks bsork to remind us, i think got it clear in the head now.

on the script,in V5 version(i got a version for making layouts, but shhht), i guess should replace:

PROCEDURE Callback(n : Integer);
by
PROCEDURE Callback(count : Integer);

had no reset but that's a perfect training!! manage to get it like this:


VAR reset, counter : tParameter;
VAR count : Integer;

PROCEDURE Init;
BEGIN
reset := CreateParam('reset', ptButton);
SetIsOutput(reset, FALSE);
counter := CreateParam('counter', ptDataField);
SetIsInput(counter, FALSE);
END;

//PROCEDURE Callback(count : Integer);
//BEGIN
//END;

PROCEDURE Process;
BEGIN
IF (GetValue(reset) = 1) THEN BEGIN
SetValue(reset, 0);
count := 0;
END
ELSE BEGIN

SetValue(counter, count);
count := count + 1;
END;
END;


didn't really understood yet the "callback procedure" process concept, bypassing it work as V4 but allows new things?.. yeah my first script diving!

[bsork]

@23fx23: Maybe you can replace the variable name n with something else in the Callback declaration - I haven't tried. In the help, n is used, and it gives the number of the parameter being updated. (BTW, the parameters are just integers starting from 0.)

You can make most V4 scripts work as a V5 "FastScript" just by adding "PROCEDURE Process" before the main block, and change the ending "." to ";". Some complicated scripts might take some more work, amongst other things because the old script engine was a little more forgiving about minor syntax errors and such.

The concept of the Callback is that it is called once for each updated parameter before Process is being called. This has several advantages:
- Move the reading of input values outside the main body of the program (ie Process). That is, if you need to have Process at all.
- As long as you don't need to do anything at all in an execution block without anything at all happening at the inputs, no resources are used to check input value changes etc. to see if something should be done. With scripts like these, you don't need Process. Or - if you have for instance som heavy calculations whenever input values are changed - set some boolean variable=true in Callback, add Process with a check on that variable, and if it's true do the calculations and set the variable back to false. If nothing happens with the inputs in the next execution block, the only thing that's done is just a check of that variable.

I find that this concept also gives me the opportunity to write simpler scripts when there are a lot of input parameters, as I often have made rather convulted IF constructions to avoid reading parameter X, Y, Z... that are of no interest because parameter A is of some value.

About the simple Callback procedure I added: In most cases, Callback would/should have a CASE or some IFs to check which parameter is being updated, but in this case there was no use for it as there's only one parameter. So it has a simple logic: If anything at all happened at the input, reset the counter. Your version would use a tiny bit more CPU than mine.

@amiga909: Sorry, should've understood that you were thinking of Usine internal resolution, not midi clocks. I'm afraid I don't know what resolution Usine operates with, Senso will have to comment on that. I agree that midi clock sync in/out ideally should be a part of Usine itself, and not be part of patches where you obviously end up with a smaller resolution plus latency.

[23fx23]

thanks a lot for that explaination. think i ve understood, at least the theory! will try to reinject it.

between I used it to queue each array of audio one after the other, works like a charm, got a full rez wavform preview I can zoom in, modify/reuse ect.
nearly got the perfect triggered oscilloscope for my purposes i had in mind!!