Feature Request - Audio File Player Widget Additions

Hi,
I’m really enjoying Gig Perflormer. It’s a great intuitive solution.

I have some feature requests around the Audio File Player Transport:
I’ve noticed the playhead position, set marker now and play from marker which have their uses. However it’d be great to be able to use the full set of transport controls available on something like a Roland A800 pro.

Ideally I’d like fast forward and rewind buttons with a speed parameter if possible, and the ability to set a series of markers within an audio file player in a rackspace with additional widgets to move to the next marker or previous marker (great for rehearsing medleys etc.)

Another one for the wish list, but for me at least it would massively enhance the usability of the Audio File Player.

Cheers,
Roger

Hi Roger,

fast forward and rewind is already possible, just assign a knob to the playhead position and by moving the knob you can scroll forward or backward in the audio player.

Speed, yes this would be great but that requires some kind of speed shifting, this is not
easy to implement without introducing artefacts.

And with different variations and scripting you can build as many markers as you want.
The idea is in the on Variation event to set the value of the widget assigned to the playhead position to a discrete value.
This is a little bit tricky because the whole length of a song equals the value 100 of the widget.

hi,
Thanks for this. I already have a knob set up for playhead position, but it isn’t granular enough in its current state. However, it does the job in a clunky sort of way.

Variations to achieve markers are out for me, at least in a rackspace that would be used live because I originally tried using program changes to select the first variation in a rackspace and assigning up/down buttons to select between sounds within the rackspace. Unfortunately I got glitches in the audio when jumping across say 2 variations so I’ve changed to a setup similar to my korg arranger where all the sounds play all the time in the single variation, and are controlled with faders. Also, if I had to have to guess the required values in terms of 0-100 I could more easily chop the audio into sections in Wavelab and play those in separate rackspaces instead.

Hence my suggestion around improving the transport controls within the audio file player itself.

I don’t know anything about the details around programming complexities, but I do know that every DAW has this functionality so it must be possible and it would be a massively useful feature to add to Gig Performer, for me at least.

Cheers,
Roger

Hi Roger,
I am using audioplayer in many rackspaces with different variations and do Not Face any Audio glitches.
Are you sure the Widget assigned to Song Position Pointer does ignore Variations.
Ignore variations is very important.

hi Paul,
The glitches happened before I added the Song Position Widget.

All my variations were doing was changing the MIDI channel to play different instruments loaded into Halion slots. My laptop has 16GB of memory so no issue with loading everything required. It was ok toggling up or down a single variation, but double toggling caused the glitches. Not a big deal because I’m happy with having all the instruments on the same channel and adjusting the levels with faders like with my arranger keyboard.

Thinking about my feature request further, it would be better if all the transport functionality could be taken to the global level (like the play button with the audio file players set to sync). That way this could be setup once for all rackspaces.

Cheers,
Roger

I do not understand why changing a midi channel could face audio glitches.

How did you implement that?

By changing the output channel in Midi In plugin?

Another possibilty would be:

include as many Midi In Block as channels are needed.
Each Midi In Block sends to a different channel.
Each Variation blocks the Note On Event for the channels not needed.

Did you try that?

I am writing this options because muting audio is a possibility, but the CPU Usage is high.
I think only send on midi channels when needed is the better approach.

Thanks Paul.
I’d setup the variations to transpose the MIDI channel output from channel 1 according to the sound needed. However, to prevent the possibility of hanging notes, I’d added the script to send a panic message on variation change which may be having an impact with too rapid variation changes. So the rackspace was set up with a program change calling up the first variation in each song, and then I’d set up pads to move up and down the variations. I’d also selected the option to not allow up / down variations to leave the rackspace.

I must admit that whilst I currently have a system based on faders with everything on all the time, it’s not the most elegant. My laptop is a fast quad core so unless I want to use several CPU heavy VSTIs in a rackspace it can easily handle the load.

Over the weekend I’ll revisit variations on one of the more complex rackspaces to try to understand the issue further and try your approach of using several MIDI in blocks.

I have a question around scripts - how can I remove and re-add the scripts to aid testing?

Thanks,
Roger

In the script editor on the upper right side there are 3 buttons

The + sign opens a new tab where you can place your code, but this is not active
With the left of the 3 button you can paste the code from this new tab to the script tab.

You can add as many tabs as you want and always past the active tab to the script tab.

But keep in mind: This additional tabs are not save when you save the gig.

By the way: You are right, changing the midi out channel in the Midi In Plugin could lead to the problem
of hanging notes.
Therefore using different Midi In Plugins and Filter Note On Events is better and its is completely save.
And doing this way you have the same effect as you have with patch persist.

Example:
You have 2 Midi In Plugins, one for piano and one for strings.
In the 1st variation you block the Note On Event, so you can hear the piano but not the strings.
Now you play a chord and hold down the keys, you switch to the 2nd variation.
You still hear the piano but with the next keys you hear the strings sound.

Same happen when you play a chord in the 1st variation, press the sustain pedal, release the keys,
switch to the 2nd variation.
You hear the piano sound until you release the sustain pedal.

This possibility of a “patch persist” within variations is a live saver when you have to use backing tracks.

That is brilliant! - I’d seen a suggestion around using another instance of GP to run the backing tracks but I really want to have the entire song performance in a single savable rackspace to be able to build setlist .gig files out of rackspaces, and your approach would make that possible.

I’ll drop that panic script and test this ASAP.

My original feature request about audio file player transport still stands though because it would enable a “live” rackspace to have the flexibility to work in a rehearsal scenario.

So my “User Story” would be:

  • On a global level have controls for play, pause, fast forward, rewind, go to previous and go to future marker
  • In the Audio File Player set markers in terms of time (rather than 0-100)

“In the Audio File Player set markers in terms of time (rather than 0-100)”
Better bar/beat

That wouldn’t work in the context within which I work.

To me a medley backing track usually comprises several songs in several tempos, which could include varied tempos within specific songs, so even if there was some means of defining those tempos to GP it wouldn’t work.

So my suggestion of simple absolute time markers is the only way.

So, basic shuttle controls for the audio backing track are currently a big missing feature.

For the Audio Player Enhancements, did you contact GigPerformer support via a ticket?

hi,
I raised a support ticket for the Audio Player piece.

I tried the block note on buttons approach. Initially I was getting system crashes, but it turned out that I hadn’t removed the panic script. Now that’s removed the variation shifting works like a charm.

Fine, good to hear that this working.

I’ve added the suggestion our tracking system. Thanks