Pause requires 'doubleclick' the first time

[Ansible]

I'm controlling SL with an old digitech rp10 pedal, using "CC" messages. I'm able to start and stop recording well enough, but pause is problematic. After I record my loop I have to click pause twice to get it to work. After that its single clicks for pause/play.

I remapped pause to my other button that I was using for record (which seems normal), and it has the same symptom there. Any ideas as to what's going on?

[kasbah]

You might want to use a midi monitoring program to see what messages are being sent.

You should also be aware that you can bind commands to either "note", "note on" or "note off". If you bind to "note" then the command will trigger on both "note on" and "note off". This can cause problems sometimes.

Let me know how you get on.

[Ansible]

Thx for the suggestions. I installed kmidimon to watch the midi events.

I can't send note messages from my pedal, at least I don't know how to do that. The pedal emits CC messages and PC messages. I use the CC messages since you can hit the same pedal twice and get the same 'data1' value each time. The PC pedals will toggle between two PC numbers generally.

So in the log below the last number on each line is 'data2' according to kmidimon. That indicates whether the effect on the effect pedal is on or off. Not relavant to operating sooperlooper. 'data1' is either 21, which I have assigned to Record, or 22 which is assigned to Pause.

The pattern seems to be this:

162794,453.1748,132:0,1,Control change,21,127, *21 = recording*
164992,457.7535,132:0,1,Control change,21,0, *recording stopped*
166263,460.4013,132:0,1,Control change,22,0, *22 = pause. but nothing happens!*
167383,462.7348,132:0,1,Control change,22,127, *now pause happens*

186836,503.2614,132:0,1,Control change,21,127, *recording*
189353,508.5054,132:0,1,Control change,21,0, *recording stopped*
190419,510.7263,132:0,1,Control change,22,127, *pause works!*

It seems like sooperlooper is ignoring the 22,0 message for some reason, but once it recives a 22,127 message it starts recognizing the 22,0 message again.

[kasbah]

I tried testing your usecase and there were all kinds of problems with getting record and pause to trigger correctly if I didn't select the "sus" option in the "Command/Control" section in the midi bindings preferences. Have you got this selected?

[Ansible]

No, I was not using sus. I turned that on but still the same result! I was wondering about that 'sus' thing though, I'll have to read up on that.

[kasbah]

That's very strange I should be able to reproduce this. As far as I understand it SUS makes the action a momentary switch. The docs on this are a bit confusing. But if I don't use it then it seems to do an undo if I send a 0 message on any CC. Strange that it doesn't behave the same for you.

I am using VMPK with some custom switch controls to reproduce what your pedal is doing. Do you think you could try it with that? You can edit the "extra control" and add some button switches for the CC messages that will alternate between sending 0 and 127.

EDIT: Just tried it again and indeed pause doesn't trigger if you send a 0 message. It works fine if you send a 127 message to go into pause and then a 0 message to unpause. Can you set your pedal up so that it will always send 127 to go into pause rather than a 0?

[Ansible]

EDIT: Just tried it again and indeed pause doesn't trigger if you send a 0 message. It works fine if you send a 127 message to go into pause and then a 0 message to unpause. Can you set your pedal up so that it will always send 127 to go into pause rather than a 0?

Thanks for checking all this out! As far as I can tell there aren't many options for configuring the output of the pedals - they send the messages they send and that's it. You can change the channel they send them on, but I didn't see anything else.

I guess from here its either check on firmware updates that might include more midi options, or perhaps find/write a program that modifies the midi messages to always have '127' in the data2. Or, get the sooperlooper source and change that!

[kasbah]

What I meant was that initially when everything is playing your pedal should be in the 0 state. Then when you want to pause you hit it and it sends 127. Kind of like you described what your record pedal is sending:

162794,453.1748,132:0,1,Control change,21,127, *21 = recording*
164992,457.7535,132:0,1,Control change,21,0, *recording stopped*

It should work that way as long as it is 127 first then 0 not as you described what your pause pedal is doing, 0 first then 127.

166263,460.4013,132:0,1,Control change,22,0, *22 = pause. but nothing happens!*
167383,462.7348,132:0,1,Control change,22,127, *now pause happens*

Beyond that I have been thinking about working on simplifying the midi bindings for the user. Re-working the commands to be combinations of simpler commands rather than having stuff like RECORD_OR_OVERDUB_EXCL_NEXT which could be broken down into the individual commands it sends depending on state and input. If I work on that I will look at the CC bindings as well. To me it would make more sense if it simply triggered on any kind of change rather than being dependant on the value. Or at least that should be configurable as well.

[Ansible]

Ah yes... good point. If I have the presence of mind to get the pause pedal in the off state before I get going, all is well, mostly.

I got sooperlooper to compile!

I see that in the "MidiBridge::incoming_midi" function there's this code:

// convert noteoffs to noteons with val = 0
if ((msg[0] & 0xF0) == MIDI::off) {
b1 = MIDI::on | (b1 & 0x0F);
b3 = 0;
}

I wonder if I could just do something similar to check for CCs here and hardcode the other data values (b2, b3 I guess?) to 127 or whatever. Probably would break other things that people use CCs for perhaps... anyway no time to try it out right now, but I will later.

[kasbah]

You could also try mididings to change the CC message to something that will work better.

[kasbah]

Just to update on this. I have implemented "CC Off" and "CC On" binding types that are the equivalent of the "Note On" and "Note Off" but for CC messages. If Jesse is OK with it these should be in the next release.

[Ansible]

Just to update on this. I have implemented "CC Off" and "CC On" binding types that are the equivalent of the "Note On" and "Note Off" but for CC messages. If Jesse is OK with it these should be in the next release.

Cool! So then I could make a 'cc on' binding and a 'cc off' binding for pause, so that either one would trigger pause. Thx for implementing that!

[kasbah]

So then I could make a 'cc on' binding and a 'cc off' binding for pause, so that either one would trigger pause.

I guess it would make more sense if you could do it with one binding. It should really work that way already. I will look further into it.
By the way when I test this case, if I don't select the "SUS" options it seems to do an UNDO_ALL instead of unpausing. Have you experienced this?

[Ansible]

sorry for the late reply! No I haven't seen the 'undo all', but I haven't used SL in a week or two. I'm not a very advanced user, I'm not sure how I would recognize it if there was an undo_all event. But if I do see that I'll post here.

[kasbah]

I'm not sure how I would recognize it if there was an undo_all event.

The whole loop disappears and returns to the "Off" state.

[kasbah]

Another update. This was actually an issue with the way the GUI handled the binding. If you want a quick fix you can edit your .slb file and change the CC binding that looks something like this:

Code: Select all

0 cc 21  note pause 0  0 1  norm 0 127

to

Code: Select all

0 cc 21  hit pause 0  0 1  norm 0 127

If you change the binding though and save it then your change may be overwritten.

If you feel so inclined you could compile my development version where the fix is permanent (although the binding file will still need to be changed): https://github.com/kasbah/sooperlooper