Could I commission someone to build this Song Selector?

Unless I’m missing it, it seems strange that there hasn’t been this sort of “preset” switcher (yes I know that’s the wrong word for it in GP land, but its how the guitarists would likely see it called) in Gig Performer yet.

I would like to see something like this, where a bank of 8 songs from your setlist could be shown on clickable/MIDI assignable widgets, which would display the song name of each.

Clicking one of the song widgets would switch to that Song in the Setlist (maybe something similar for Rackspaces too?)

Clicking the bank up or down would display the next or previous 8 Songs on the Setlist and allow them to be selected if chosen. Optionally, wraparound could be turned on or off when you reach the first or last set of 8. Also optionally, it could display the next/previous four songs instead of 8, if that makes sense, so that it would say show 1-8, then bank up once would show 5-12, etc.

If possible, there could be a show/hide panel switch, ideally not even a rack panel, but a floating window that I see in other extensions, that only shows when that show panel button is pressed.

If possible, this panel could only switch songs when Show Panel state is true

if possible, selecting a song could optionally automatically close the panel

Is this doable in Gig Performer? And is there anyone who would like to do it?

1 Like

Are you implying that you would want your midi controller switches to control something completely different when the panel is closed?

Yeah. I want to get it as close to existing multifx paradigms as I can. In those cases often in preset selection mode the (often 8) foot switches pick presets and once a preset is loaded they switch to stomp and/or snapshot mode

Dave Boulden’s Song Selector doesn’t do what you are looking for?

Not as far as I could tell, but I could use it for a paradigm breaker personally, using an expression pedal to scroll and a button to select. But as far as I can tell it cannot populate a pedalboard’s buttons the way normal multi-fx do…but perhaps I didn’t dig into it deep enough. I was playing with it all last night after a show, but could have been groggy, I may try some more today.

I haven’t looked into it deeply (I don’t use it). But my impression is that it was set up for a controller with buttons. Each button would allow you to select a song (I guess a PC message triggered by a widget).

I would think you would just trigger it with 8 pedals instead of controller buttons.

But, there is a good chance I may be missing something.

(I don’t know if Dave’s paid extension has been updated. My impression (based on very little) is other free extensions have been created, so not sure of the status of the different options (Dave’s and others).

I’m going to look at it again. I’ve been using Rank13’s to do a kind of cool scroll with my otherwise wah pedal

Well, the standard setlist view shows all the songs down the left hand side and the song parts across the top, in multiple rows intended to be easy to map to a pedalboard configuration.

But part of the problem here is not leveraging GP’s paradigm. In the example you show, the pedalboard itself has to be configured with song names and (presumably) program changes for each bank.

In the GP world, there is no need to do that - you configure your pedalboard so that each button has a CC number and sends 127 when pressed and 0 when released. Then GP itself handles the interpretation.

In that approach, there are almost an infinite number of ways to configure the system depending on the desired approach and it’s simply not practical for us to create all of them. Most things can be done with a combination of OSC and/or GPScript and of course third-party extensions can be developed.

For example, I use an iPad with some scripts developed with Lemur that let me access setlists, songs and individual control over each song (see first set of images)

One of our users developed a really cool interface using TouchOSC and that can work on either an iPad, an Android device or within an application running on the same machine.

I use a GT Mastermind Pedal Board which was most certainly developed for guitarists but since it can be configured using real-time sysex messages, a reasonably simple GP Script running as either a gigscript or in the Global Rackspace makes it completely unnecessary to configure the pedalboard at all. Here’s an example of how I have it configured.

With just a little bit of programming in GP Script, one could make this automatically display multiple songs, song parts for the currently selected song and instead of the two buttons on the bottom right that I use for scrolling pages on a sheet music viewer, those could be used to tell GP to display the next set of songs in a setlist (for example). Now, the guitarist doesn’t even need to look at his/her laptop at all, making a “preset switcher” view completely unnecessary - everything is at his/her foot and/or on his/her iPad.

So the approach is far more open-ended than just hard-coding a single “preset switcher” view.

We see more and more guitarists working with GP - this facebook post just appeared a day or so ago as the most recent example. He’s using a Nectar Pacer.

3 Likes

I’m not sure which other popular MIDI pedals would allow this thru sysex, but I imagine it would need to be done for each model? I want to be able to present a way that anyone could use it with any reasonable MIDI pedal they will likely be using.

You hit it on the head, the guitar player really doesn’t want to be looking at the display screen, maybe for the tuner, but aside from that, if the midi pedal cannot display names, they’d be looking at the names scrolling by and what preset each pedal calls up, but that’s it.

It seems like a lot of the users have these devices at head level so they are used to touching them, for a lot of guitar players, this thing will be on the floor and not as easy for old backs to interact with

The existing system actually works great for four or five songs or rackspaces, but after that it seems to require some touching of the screen

Not really - the GP Functions that talk to the Mastermind could easily be replaced by functions with the same name to handle other pedals, more and more of which are supporting sysex. Alternatively, building simple third party extensions to use proprietary pedal APIs is not that hard and these days, the GP third party SDK allows an extension to “insert” GP Script functions back into Gig Performer, thereby extending the GP Script system library.

Lots of possibilities.

Why? You can send commands from an external device to navigate just about anywhere.

There are a lot of old pedals people still use out there, the Boss ones, Bradshaw, Rocktron, DMC, it seems like it would be more practical to do this over MIDI so it could be rather universal.

I’ll see if there are Sysex functions I can get to on the FCB1010 and an FCB1010 with the Uno chip, but I’m not sure if the other parts, like the grid display would still not need an extension? I’m not super sure what could be accomplished.

The RJM controllers are great. You could also have a look at the Morningstar MC series pedals which integrate nicely with GP via the extension @Vindes made

I think I need to break this down into a few different tasks.

For one, I’d want a window or rack panel (ideally it would only show during preset selection but not the end of the world if it is always present) that populated a grid of two rows by four columns with 8 songs at a time, and each cell, when pressed (or sent a MIDI command), selects a song (and ideally hides the window or panel with the grid on it). Also this would need a way to move up and down in banks of four or eight songs. I think if I could get this figured, the rest shouldn’t be too bad.

Even if I were to use sysex messages to do this with the controller, I expect I’d still need this grid to be functional as shown here.

I have an MC8 pro and a Paint Audio Midi captain on order, I can’t wait to try it with this.

But I do have to make sure everyone’s existing MIDI controllers also work with this, and many of these guys are pretty much married to their existing controllers

What you’re describing is more or less how the logic of the MC8 extension works. Using GP language, it can do “Show rackspaces, then switch to showing variations when a Rackspace is selected”. Same for Songs & songparts.

What I don’t see in your description is how the user is going to tell it to change back to Rack or Song select mode when it’s time for the next song.

Having the MC8 extension display what it shows on the MC8 screens onto widgets is a pretty trivial addition. Having the FCB1010 send the CC’s the MC8 extension expects from the MC8 just requires programming the FCB1010 to do that. The “bank up / bank down” buttons could also be programmed on the FCB1010.

That would occupy buttons 1-10 on the FCB. I don’t remember if the FCB will let you assign midi messages to the BankUp and BankDown buttons. If those are programmable then it’s effectively a 12 button controller and what you’re describing should be a pretty simple modification to the MC8 extension.

Getting it to show the song or rack names on an OSC display instead of widgets should also be pretty trivial. Having that display pop up on a separate window wouldn’t be terribly complicated, but JUCE graphics are outside my experience.

Same thing should work with the Midi Captain, and because I believe you can do separate short and long presses on the BankUp/BankDown buttons it should have sufficient buttons I think.

I figure for showing or hiding, a show/hide button could be added like in the picture and have a MIDI assignment to it, or just one to open it and picking a Song automatically closes it, but really even if the window is always on its not the end of the world. While I could use a different bank to select songs, it would be nice not to have to and just use the same messages that the pedalboard is already sending in the bank its already in, but its not the end of the world if the controller has to switch banks to pick songs

I’m not sure how the OSC display thing would go, would it be something showing inside Gig Performer?

I really need to make sure that pretty much any MIDI controller with enough switches will work with this. I haven’t tried your MC8 extension yet, but I guess I should download it and see if it lets me chose assignments or if I can set the FCB to the right MIDI values

@Vindes The Bank Up and Bank Down switches on the FCB1010 are programable if using the Tinybox mod. IDK if this is true for the Uno or other mods. Add the line NO_UPDOWN_SWITCHES to your setup before the bank definition, and you will be able to specify 12 presets in one bank instead of 10. Any preset button command including midi messages are allowed.

1 Like

As long as there assignable widgets or whatever for bank up and bank down, we’ll figure a way to assign them

I’m still also unsure if this actually needs to be an extension, or if it could be scripted or if I am just not clever enough to make it work with the existing functions and widgets.

For the most part anything that can be done with an extension can be done with scripting.

I don’t think there’s a way to do what you want to do without one or the other.

What you want this thing to do is non-trivial primarily because you want one physical button on a controller to control multiple things. The first question to decide is whether you try to build some of that logic into the foot controller, or you push all that logic to GP.

If you want all the logic in GP, then you start by setting the FCB1010 (for example) to always send the same midi events when a button is pushed. Like the first button always sends Note 0, next button Note 1, etc. Then your logic in GP has to keep track of what “state” the foot controller interface is in, and the logic for how it responds to each midi event has to check that state (e.g. select Song or select Songpart) before doing anything else.

Alternately, you could use two different banks on the FCB1010 (or whatever controller). In that case the controller knows which midi to send depending on what state it’s in. In your “song select” state the FCB would send one set of midi messages for each button, and in your “songpart select” mode it would send a different set.

Either approach can work, but if you’re trying to build something simple for users and flexible enough to work with different controllers I’d be inclined to plan for all the logic to be in a script/extension. I’d try to minimize the number of places where something set incorrectly could cause problems.