making two samplers have identical loop lengths

[woodslanding]

I'm trying to make a looper, and I've modified the echoplex addon to where it is working for me as a one channel device.

I'd like to extend this to 4 channels, and here is my difficulty:

I'd like to insure that after the master track is recorded, all other tracks have some multiple of the length of that track. I'm starting with just 1x. If I get that working I'll try other multiples. But there is no input for 'length' on a sampler module.

Here's how I figured to do it. I take a position input from the master track, and when the record button for a slave track is pressed, the value of position is stored in a variable. When that variable once again is equal to position, I want usine to automatically turn off record. This way I have a new recording that is exactly as long as the master (but with a different loop point!)





If I test for equivalence between my stored position and the new incoming position, they are never equal. I have gotten it to work by truncating both values, but the tracks are drifting badly....

I'm sure there must be a more elegant way of doing this, but I'm not thinking of one.....

[bsork]

You could try with >= instead of truncation and = and see where that gets you. You might also find something of interest in my (old) add-on
PunchInPack which is based on something similar.

[nay-seven]

if you talk about the live echoplexx patch, what about using the len(ght) outlet of the sampler to feed a count milllisecond sub-patch to start your layers record..?

edit : test the addon of bsork before of course..

[woodslanding]

thanks for the tips--I will give these a try.....

[woodslanding]

well, I tried >= and I'm still getting drift. So I guess I will try to figure out how to count ms.....

[nay-seven]

for info the sub-patch is in :
Modules/ synchro &Time/ count milliseconds

[woodslanding]

well, I tried it with count ms, and although the counts are the same, I'm not getting the same length in the second file. It does work tho, and is very simple (although what's inside countMS is not so simple....)

Okay--figured out a failsafe way to stop the drift: I stopped using loop mode in the slave. Instead, it gets triggered every time the master loop reaches the value that the record button was at when pressed!

I think this will work!

thanks,
-e

[bsork]

Okay--figured out a failsafe way to stop the drift: I stopped using loop mode in the slave. Instead, it gets triggered every time the master loop reaches the value that the record button was at when pressed!

Actually, trigging one-shots is probably the only way to keep the loops from drifting. Even when you got the milliseconds right, if you use loop mode the number of samples should fit each other perfectly to avoid drift altogether. And then it's the zerocrossings to take into account...

Don't know why I didn't come to think of this when I first saw your post...

[woodslanding]

one problem I'm still having:

I'm toggling record on the master track from a midi footswitch, and there is about a 100ms delay in starting record, but no delay in stopping it. So my loops are ending up short, and much of the first beat gets truncated.

I'm using the simple echo addon. I wonder if there is some wiring there that is delaying the start of record. I'll see if I can simplify the wiring, but it's all pretty simple already.

Or is this just a function of how the sampler module works??

[nay-seven]

could be several thing
midi latency ,
the switch rec is not quantize.?
have you try several remote mode ( relative, toggle)
have you check what the footswitch is sending exactly..?

[woodslanding]

I assume the remote modes refer to midi learn? I can't use that because my footswitch (FCB1010) sends midi notes, which I have to convert to CCs..... so they are wired in directly. However, I do use the CC to affect the toggle input on the record switch. Do you think that could be it?

I did not know switches could be quantized. I'll have a look at that. But the same switch starts and stops record, and only the starting runs late. Or at least it always runs later than the stopping does!

Well, I will mess with it more. Thanks for the suggestions.

-e

[bsork]

I assume the remote modes refer to midi learn? I can't use that because my footswitch (FCB1010) sends midi notes, which I have to convert to CCs.....

Just for the record, you can also use notes for the MIDI learn, so unless you have to filter them to avoid unwanted note messages somewhere, use them as they are.

Regarding the delay, are you sure the switch reacts when the pedal is pressed, not released?

[woodslanding]

hmmm, I have had no luck midiLearning on notes.... I'll try again.

Actually, midiLearn broke on me last night, and I haven't figured out why yet.

With regard to the switch: I have a script to convert a note to a switch (below), which goes into a 'has changed' module, leading into the toggle input on the record button. My expectation was that this would cause the switch to be on only while the pedal was held down, but it doesn't work that way--so you may well be right. I'll check into it.

I have new software for my foot controller, which I am going to install tonight. This will allow it to send out CC values, and I'll need to rebuild this stuff anyway. Maybe it will fix the problem.....

thanks!

NOTE-> SWITCH SCRIPT

Code: Select all

////////////////
// parameters declaration
const NOTENUM = 2;
var input   : Tparameter;
var switch  : Tparameter;


// initialisation : create parameters
procedure init;
begin  
 input := CreateParam('In',ptMidi);
 SetIsOutPut(input,false);
 
 switch := CreateParam('Switch',ptSwitch);
 SetIsInput(switch, false);

end;

// Global variables
var i            : integer;
var nbOfMidiIN    : integer;
var ReceivedMidi : TMidi;

//////////////////////////////
// main proc
//////////////////////////////
procedure process;
begin
 nbOfMidiIN := GetLength(input);  // get the number of incoming midi codes  
 if nbOfMidiIN > 0 
 then begin
   for i := 0 to nbOfMidiIN-1         // loop for all input codes, for polyphonic data (chords)
    do begin
      GetMidiArrayValue(input,i,ReceivedMidi); // get each code

       if ((ReceivedMidi.msg = 144) and (ReceivedMidi.data1 = NOTENUM)) then begin
           if ReceivedMidi.data2 > 64 then setValue(switch, 1) else setValue(switch, 0);
       end
       else if ((ReceivedMidi.msg = 128) and (ReceivedMidi.data1 = NOTENUM)) then setValue(switch, 0);
       end;
    end;
 end;

[bsork]

hmmm, I have had no luck midiLearning on notes.... I'll try again.

Hm, that's strange. :/ Hopefully, you have better luck with the updated software.

With regard to the switch: I have a script to convert a note to a switch (below), which goes into a 'has changed' module, leading into the toggle input on the record button. My expectation was that this would cause the switch to be on only while the pedal was held down, but it doesn't work that way--so you may well be right. I'll check into it.

Reading your script, I find it strange that it shouldn't work. Anyway, you're making it more complicated than neccesary: You don't need the HasChanged->toggle setup - just connect the output od the script directly to record on the sampler. If you want a visible record switch as well, use script->PassIfChanged->switch->sampler.

If you get the MidiLearn working you shouldn't need a script anyway, but I'd like to mention that you can use the Callback procedure and drop Process to save some CPU as it will only do anything if values change, not every block. Eg:
[c]PROCEDURE Callback(n : Integer);
BEGIN
IF ((n = input) AND (GetLength(input) > 0) THEN BEGIN
FOR i := 0 TO GetLength(input)-1 DO BEGIN
...
[/c]

[woodslanding]

Okay, lots new now. Thanks for the tip--that is an old script that I modified, and I guess I didn't do it correctly!

I got the new software for the FCB installed, and now I can send CCs. But I am still having the problem with the start of recording being delayed... about 100 ms. I've uploaded my patch and it's here:

http://www.sensomusic.com/forums/upload ... oopers.pat

there is now a direct line from the record button to the sampler, and it's definitely responding on button down, as I put in a 1 to 0 module.....

Any thoughts?? I will try it outside of my wkp, and make sure I get the same results.... Maybe it matters that it's inside a subpatch too??

Anywa;y, the stop of record is not delayed at all.

thanks for any ideas....

-e

[nay-seven]

i've saw that the first rec button is directly connect to the sampler , but not the 2,3 and 4..
cause they pass trough the count milliseconds sub-patch , so i've add a direct wire ( i've also keep your old one ) to the rec inlet of the sampler , this way the rec is direct and the count millisecond is use only to stop...?

[woodslanding]

you are right.... but the problem happens with the first sampler--there are issues synching the other samplers up, but that is a separate issue--which the count milliseconds are used to adjust for. It doesn't matter when the others stop, as they are always restarted by loop one, rather than looped.

The problem I mention affects the first sampler. Sorry that wasn't more clear.

[nay-seven]

mm, so can't see any reason in your patch......have you tried different pedals of the fcb1010..? different remote mode ..?

[woodslanding]

I get the same effect when I just press the REC button.

I guess I will start with an even simpler setup than Olivier's simple echo, as this patch has had this problem for me from the beginning.

I guess it's not a known bug with the sampler. Or with this patch. Could it be something in my settings?? I run the interface slow, but that shouldn't affect midi response ( it would affect the button response though, right?)