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?)
Statistics: Posted by woodslanding — 18 Oct 2010, 01:28
]]>
]]>
The problem I mention affects the first sampler. Sorry that wasn't more clear.
Statistics: Posted by woodslanding — 17 Oct 2010, 09:37
]]>
Statistics: Posted by nay-seven — 16 Oct 2010, 22:19
]]>
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
Statistics: Posted by woodslanding — 16 Oct 2010, 21:07
]]>
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.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.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.
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]
Statistics: Posted by bsork — 06 Oct 2010, 08:28
]]>
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:
////////////////// parameters declarationconst NOTENUM = 2;var input : Tparameter;var switch : Tparameter;// initialisation : create parametersprocedure init;begin input := CreateParam('In',ptMidi); SetIsOutPut(input,false); switch := CreateParam('Switch',ptSwitch); SetIsInput(switch, false);end;// Global variablesvar 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;Statistics: Posted by woodslanding — 06 Oct 2010, 05:56
]]>
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?
Statistics: Posted by bsork — 05 Oct 2010, 08:11
]]>
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
Statistics: Posted by woodslanding — 05 Oct 2010, 03:55
]]>
the switch rec is not quantize.?
have you try several remote mode ( relative, toggle)
have you check what the footswitch is sending exactly..?
Statistics: Posted by nay-seven — 02 Oct 2010, 20:40
]]>
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??
Statistics: Posted by woodslanding — 02 Oct 2010, 19:12
]]>
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...
Statistics: Posted by bsork — 30 Sep 2010, 11:54
]]>
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
Statistics: Posted by woodslanding — 30 Sep 2010, 10:31
]]>
Statistics: Posted by nay-seven — 30 Sep 2010, 09:02
]]>
]]>
]]>
edit : test the addon of bsork before of course..
Statistics: Posted by nay-seven — 29 Sep 2010, 09:06
]]>
Statistics: Posted by bsork — 29 Sep 2010, 08:57
]]>
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.....
Statistics: Posted by woodslanding — 29 Sep 2010, 07:02
]]>