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!!
Statistics: Posted by 23fx23 — 02 Dec 2009, 10:30
]]>
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.
Statistics: Posted by bsork — 02 Dec 2009, 08:54
]]>
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!
Statistics: Posted by 23fx23 — 01 Dec 2009, 22:59
]]>
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.
Statistics: Posted by amiga909 — 01 Dec 2009, 21:11
]]>
]]>
]]>
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.
Statistics: Posted by bsork — 01 Dec 2009, 12:27
]]>
thanks.
Statistics: Posted by amiga909 — 01 Dec 2009, 11:15
]]>
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.
Statistics: Posted by 23fx23 — 01 Dec 2009, 00:52
]]>
gonna test it right away! that's seems so simple "count + 1" !
script my next do do 2010 list
Statistics: Posted by 23fx23 — 01 Dec 2009, 00:43
]]>
A script would overcome the problems. Here are two versions (not tested, just wrote them and need to go to bed
):For V4:
CODE:
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;// mainBEGIN IF (GetValue(reset) = 1) THEN BEGIN SetValue(reset, 0); count := 0; END ELSE BEGIN count := count + 1; END; SetValue(counter, count);END.CODE:
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;Statistics: Posted by bsork — 01 Dec 2009, 00:18
]]>
Statistics: Posted by 23fx23 — 01 Dec 2009, 00:12
]]>
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!Statistics: Posted by 23fx23 — 30 Nov 2009, 23:08
]]>
]]>
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..
Statistics: Posted by 23fx23 — 30 Nov 2009, 22:15
]]>