Pedalboard: Chainable FX for norns

Library
, ,
187

Hey Nuno! I use PSETs to save and load pedal arrangements and settings all the time. Could you describe a bit more the exact steps you took? There also may be some output in the web logs if you head over to norns.local while your norns is on wifi

188

Sure. I enter a few effect types to the effects chain then I go to the Past menu, choose an available slot and hit save. Pretty much standard operating procedure, I suppose :slight_smile:
When I reload the script and then try to load the saved preset, I still get the same initial screen asking me if I want to add an effect to an empty pedal board.

(EDIT)

I’ve noticed an interesting behavior. I created the second pedal board and saved it as a preset on slot 2. When I initialize the script and then choose preset 2, it will load is expected. But if I try to load preset 1, which is always the default selected preset, this preset will not load. Meaning that I first have to load preset 2 and after that preset 1 if I want the pedal board on preset 1 to load.

189

Super cool Script I love it, had some great fun with it today!
I was wondering if it would be possible to run multiple versions of the same pedal in parallel.
What I would like to achieve with this is having 4 pitch shifters in parallel.
I gave it a try to make it. (please note I am new to Norns and lua).

I tried the following:
Making one more pedals by copying the pitch shifter sc en lua files, give them unique names (added a 2 at the end of the name. and add those names to Engine_Pedalboard.sc.

In the cs I changed PitchShifterPedal, pitchshifter and PitchShift.ar into:
PitchShifterPedal2, pitchshifter2 and PitchShift2.ar

In pitch_shifter2.luaI changed all the PitchShifterPedal into PitchShifterPedal2.
When I run it I get pitchshifter2_ready_poll, which seems to be a good sign but when I run the script it won’t show in the list of pedals that I can select.
which has something to do with: remove_pedal_at_index ii

Am I thinking in the right direction or is this not the right approach?

190

Hey there! Love that you’re having a go at adapting this to suit your needs :smiley: Pedalboard is a complicated script, but I tried to make it as approachable as possible under the hood. And it sounds like you’ve basically got the idea!!

So, first thing to note is: Pedalboard does not currently let you run pedals in parallel. They are always in series.

Otherwise, what you did sounds basically right. PitchShift.ar however should stay PitchShift.ar – that’s a built-in SC class, not “part” of Pedalboard.

The full list of places that define a pedal X are:

  1. a lib/fx/X.sc file with XPedal : Pedal defining the class
  2. X.sc should have *id { ^\x; }
  3. lib/EnginePedalboard.sc should list XPedal in the allPedalDefinitions list (matching the classname from #1)
  4. a lib/ui/pedals/x.lua file with local XPedal = Pedal:new() defining the class
  5. x.lua should have XPedal.id = "x" (this string has to match the ID from #2)
  6. lib/ui/board.lua should list include("lib/ui/pedals/x") in the pedal_classes list (matching the path from #4)

It sounds like you did most all of those, but figured it’d help to list em all out :smiley: Definitely make sure you’ve done steps 2 and 5, and given the new pedal a unique ID that matches in both places! (it reads like maybe you did #2 to set PitchShifterPedal2.sc to have *id { ^\pitchshifter2; }, but you didn’t set pitch_shifter2.lua to have PitchShifterPedal2.id = 'pitchshifter2')

Last note: I don’t believe that showing up in the list of selectable pedals would have anything to do with remove_pedal_at_index. That latter function is called when you’ve already added a pedal to the board / signal path, if you want to remove it from the board. It has nothing to do with the list of pedals that one can select.

1 Like
191

Thank you so much for the detailed explanation! I got the second Pitch Shifter pedal working now. I didn’t do step 6 and that why it was not working. Now I’m going to repeat all the steps to create 2 more.

Do you maybe have some general directions what I would need to change to run the pedals in parallel? Or would it be to hard to achieve this? (I can imagine it would be).

1 Like
192

The basic idea would be to edit the insertPedalAtIndex and removePedalAtIndex functions in Engine_Pedalboard.sc.

For insertPedalAtIndex, you’ll look at how the inputs and outputs are set up for the pedal being inserted: pedalboard/Engine_Pedalboard.sc at 59970c5aae48e9a6b9a8e4454678e7233b627492 · 21echoes/pedalboard · GitHub. I haven’t tested this, but you’d want to edit it to be something like the following. The general idea is: don’t make any new buses to route between pedals. Instead, just always have the input be buses[0], and the output be buses[1]. I think the SC Bus class lets this work as expected, rather than the pedals “stealing” each others’ connections.

    // Always have our inputs be the original input bus, as set up on line 88
    inL = buses[0].index;
    inR = buses[0].index + 1;
    // Unlike the existing code, we never have to make a new bus or `buses.insert` anything
    // And finally, our output is the bus at index 1
    out = buses[1].index;

For removePedalAtIndex, you’ll basically do the same but in reverse – don’t ever destroy or remove any bus. As above, I haven’t tested it, but you can probably just straight up remove lines 210 to 220: pedalboard/Engine_Pedalboard.sc at 59970c5aae48e9a6b9a8e4454678e7233b627492 · 21echoes/pedalboard · GitHub.

1 Like
193

Thanks! Today I had the time to try it out and it seems to be working in parallel!
So I went on and added a third pedal. Which kind of works, but adding a third pedal introduces a very big lag to the button control and menus. Which is strange because when I look at the CPU its not more then 25% and the audio seems fine. The code for the third pedal is also not the problem because when I run Pitch shifter and Pitchshifter3 it runs without problems. Only when I have three in total the problem arises, seems that 3 Pitch shifter pedals are too much?

1 Like
194

Great to hear that the code changes basically worked!! I’m pretty surprised that you’d be hitting CPU limitations with just Pitch Shifter pedals – in my CPU measurements, that was one of the least expensive pedals of all, at only ~1% CPU :thinking: It’s hard to imagine that the pedals being in parallel instead of serial would meaningfully affect CPU performance either. I’m no SuperCollider CPU expert though, so I don’t know exactly where to go from here. If you’d like to mess around with the SuperCollider PitchShifter pedal implementation itself, it’s pretty terse (one of the other reasons I’m coming up blank – there’s not much left to remove!!). Try e.g. hard-coding the pitch dispersion and time dispersion to zero? Or reduce the windowSize value? PitchShift | SuperCollider 3.12.2 Help