Testing out, learning MSuperLooper. I think they finally worked out lots of bugs and works well in GP for me. Very cool! Everything is self explanatory with the plugin window open, but I’m trying to see if I could use it live with just widgets, without the plugin window open.
I created a layout that sort of reflects the plugin window. It works, but the visual feedback is terrible. It is impossible to tell which track’s which loops are active, since the buttons that activate those loops are momentary do not stay “on” after selecting the desired loops. There is no way to tell which loops are active, which ones are not. They all look the same. I am using VST3, clicking the sync option in the widget midi edit doesn’t do anything.
Is there any way to get the visual representation to be dynamic and reflect what’s going on inside MSL? Unfortunately there is no default “track 1 loop 1” (2,3 etc) parameter in the plugin list, so I’m just firing CC’s to activate them, thus no syncing of states. All buttons that are not momentary (like record, play, levels etc) are fine, but all others (mainly the loop buttons) are the issue.
Melda has an incredible amount of settings deep inside the options, most of which I do not even understand. I was hoping someone has found a way to get visual syncing of widgets.
I might try out MSuperLooper again this weekend with their latest changes. My past experiences always ended in frustration.
I do think there are some strange behaviours with Melda plugins and their host automation (not always bi-directional) particularly when using the custom Multiparameters.
It is great, feature rich, works flawless. If it were possible to run it without having to open the plugin GUI for visual feedback, would be perfect! Is it even possible to get a bi-directional midi sync of a momentary switch?
One work around idea I have is to put the loop buttons in latch mode (not momentary) because the loops get activated with either 127 or 0 value. This way when a loop is activated (button pressed), it stays “lit” ON. Is it possible to deactivate it via a script once another button on the same track is pressed? Of course as I’m typing this I am realizing that after activating the other button, this one gets turn OFF, goes to zero and that will activate that loop again… Hm… Another 127 value would have to be sent for button two. So something like this:
Button 1: 127
Button 2: 127 → automatically sends 0 to button 1
→ immediately send 0 then 127 to button 2
In theory that would turn off button 1 and turn button 2 back on… Feels not very elegant though… LOL
One thing that may help is to use the multi-output version of the plugin, and then route each loop to separate channels on a GP mixer. That way you can add a meter widget - which will confirm which loops are outputting audio.
NIce loop by the way! (it was saved as part of the plugin/rackspace, so I got to enjoy it while I checked it out
Are you using the Beta version of the Melda plugins?
This might help:
Improved MSuperLooper workflow by adding access to all loops in each track. Added hidden parameters to toggle play, reverse, immediate clear, and switch between loops of selected track.
I was only meaning to route each track. For the loops, you will need a way to show this in the widgets. From what I can see, the loop parameter is a single parameter, so you will either need to accept this as a horizontal fader (instead of buttons) or create a script to make the pads highlight the selected loop.
This is similar to what was done in this Helix Native template to use buttons to select the snapshot.
Well, I spent about an hour on the script…no success. My scripting knowledge is preschool level. I took what I thought I needed, but obviously not enough as it’s not working. I wasn’t sure if the criteria by which it makes sure that only 1 button is lit at a time is based on other buttons being pressed or checking the plugin?
Here is what I did so far:
// Deselect other LOOP buttons
Function UpdateButtons(index : integer)
Var i : integer
for i = 0; i < Size(BUTTONS); i = i + 1 do
if i <> index then SetWidgetValue(BUTTONS[i],0.0) end
end
End
It complies, which is great, except it doesn’t do anything, which is not so great! LOL In the original gig file there are scripts in the reg rackspace as well as the global RS and it looked like it was also dealing with a lot of stuff I didn’t need. I just need to buttons to go off when another is selected. Can you help me with what I need and don’t need from these scripts? Thank you!
You’re ultimately needing a ‘radio button’ concept per track. First thing you’ll need to combine just the widgets on the one track together in a widget array, not have all of them together.
e.g. instead of ‘BUTTONS’ for all of them, split it into separate widget arrays for TRACK1LOOPS, TRACK2LOOPS etc.
The key callback to pick up that a widget was pressed is the On WidgetValueChanged
In the script editor, if you right click, you can find this callback, including one for ‘Multiple widgets’.
You will need a separate On WidgetValueChanged callback for each of your tracks, and list the widgets relevant for that track.
@ztones I think I have it all working.
It ended up being a bit fiddly to get it all working as expected. A lot of the script followed quite closely to what was done in the Helix Native template (but multiplied x4 because of the 4 tracks).
I have changed MSL to the 16 output version. Note that I haven’t re-mapped all the MSL widgets (only Record).
The other important point is that you shouldn’t map the track loop pads to anything. It’s all handled in the script.
Maybe it’s me, but I still find the behaviour of MSL to be unpredictable. While testing, there was an instance where activating record didn’t actually record anything. And when selecting a new loop and recording, it overdubbed the first loop. I will keep trying!
Nice work @rank13 ! Works perfectly! Have only played with it a bit but so far perfect! Question, how did you figure out that MSuperLooper parameter numbers for tracks 1-4 are 32,40,48,56 and that MSuperLooper parameter values to select loops 1-4 are 0.0,0.33,0.66,1.0??? Or is that something you assigned? Very impressive!
UPDATE: Nevermind… I figured it out. It says so in MSL when you click on them… COOL!
In the GP ‘Options > Display’ there is a preference to show the parameter numbers in the mapping list. This makes it nice and easy. You can also see the parameter numbers at the top of the plugin window, when you move/click it.
If you have a widget mapped to the Loop parameter, and then change the Loop in the MSL plugin, you can see what parameter value it used in the widget properties (Edit mode).
Thanks for the explanation. Def new info! The script / looping widgets are working flawless! I’ve had no “misfirings” whatsoever so far! I’d like to add one more tweak though. When selecting a certain loop on certain track, it only works for playback, not recording. Meaning, if I’m recording and am using the plugin window and lets say I’m on track 1 loop 1 and touch track 2 loop 2, the recording will jump to track 2 loop 2 and record there. Not so with the widgets. It selects whichever loop I touch, but the recording doesn’t move to that track/loop. I think the track has to be selected, not just the loop? Thanks!
Hm… Another 127 value would have to be sent for button two. So something like this:
