Scenes

[rerdavies]

Implement scenes.

[FoolHen]

Out of curiosity, what are them? Nevermind, read about it in the discussion thread, seems like a cool feature.

[rerdavies]

<Feature analysis, first cut...>

Part of the task is figuring out what exactly this means. :-) I get the core of the feature request. It's far from obvious to me how to implement it.

Helix has snapshots; modep seems to have a "scene" system arranged around stage performances, where each "song" gets only one arrangement of the control chains, but multiple snapshots of control settings. The core of both features is that you have a way of changing controls to snapshotted values without reloading plugins, which would introduce discontinuities in effect output (most especially for reverb tails).

So, there's some combination of the following two features, which requires serious design thought before starting on the task.

• A system that allows you to change control settings without reloading plugins (perhaps per-patch "snapshots"). Might perhaps be #3.

• an actual scene-management system which allows you to set up sequences of "snapshots" for a particular song you're playing, and then select "snapshot" collections for each song in your set (the modep approach).

The problem with Helix's snapshot-based approach: the UI affordances are awful. You can set up your footswitch to cycle between snapshots; but how do you indicate in the UI which snapshot you have selected? How do you intervene in the PiPedal UI when your singer inadvertently goes to the 3rd verse, skipping over the lead guitar solo?

The problem with modep's scene approach: a whole parallel UI to banks, in order to provide a not-entirely obvious feature (don't' reload the plugins). The UI affordances are great, though. When you're in the "scene" UI, it's easy to indicate which "scene" is selected. But does "scene management" cease when you're not in the scene UI? It seems like like a small feature ("don't reload the plugins"), provided by a bad implementation of a big feature (cue management for live performance).

Actual scene management seems like an independent feature in its own right. But doing it right would require not using modep's restriction that individual songs can't change the patch chain. What real scene management with no compromises would look like in my mind:

• You're a guitar tech working on AC/DCs road show. Your job is to set up cues for patch changes for each song in AC/DCs upcoming performance at Wembley stadium, and change patches on cue as the live performance progresses. (Or set it up so that Axel can do it himself from a tablet clipped to his microphone stand).
• You set up cue list for each song in the performance. The cue list for each song in the performance contains items like "2nd verse, huge reverb wash", "Bridge: overdrive to 11", &c.
• Be prepared for Axel to choose an encore song that isn't on the set list.
• Be prepared to jump to a different point in the cue list if the performance in the moment differs from the expected performance the cue list.
• Start working on the cues for AC/DCs revised set list for the tomorrow's performance in Hamburg.

Or obviously, the same feature but in a less grandiose form if you're playing a set at the local pub next Thursday. Cue management for live performance seems like a legitimate future feature (but not a crushingly high priority feature). It seems a shame to introduce a broken version now.

Neither approach seems entirely happy to me.

3 "Recycle plugin instances across a patch change" is also in play here. That would allow you to use banks to provide both features. The problem with that feature being that describing to users the circumstances under which effects are not reloaded when changing patches is challenging. Internally, the implementation would be pretty easy: "if the instance ID is the same, and the effect is the same, recycle the plugin instance from the previous patch", no matter where it was placed in the effect routing. The big advantage: just use the existing bank UI for scene management. The challenge with that approach is documenting to users when plugins get reloaded, and when they don't.

Still need to think through how to implement the feature. #3 is really tempting. Maybe a "Recycle plugin instances" checkmark item on the preset dropdown menu , or enable plugin recycling on a per-bank basis. But how to expose and document the feature to users?

Discussion welcome.

[rerdavies]

... #3 is really really tempting.

[BorisSutin]

In terms of the interface in your editor, you can add another view for displaying scenes. It will be the main one during the performance. At the top of the screen, add just one button to switch between editor views and display scenes. As an example of implementation, Fractal and QCortex

And my implementation, I already attached a video to you.

[BorisSutin]

And here is my concept so that it will be clearer for you.

[BorisSutin]

Also, using scenes and song will simplify playback automation. I plan to improve the lv2 wav/mp3 player with time stamps for switching scenes during playback. Then the foot buttons will not be needed) I have already done this in the mobile application for Fractal.

[rerdavies]

Thank you kindly for your analysis. All of that seems doable.

A question: do Playlist and song selections work if you're not in the Playlist/Song interface?

On Fri, Aug 30, 2024 at 9:10 AM Skyhawk @.***> wrote:

Also, using scenes and song will simplify playback automation. I plan to improve the lv2 wav/mp3 player with time stamps for switching scenes during playback. Then the foot buttons will not be needed) I have already done this in the mobile application for Fractal.

— Reply to this email directly, view it on GitHub https://github.com/rerdavies/pipedal/issues/181#issuecomment-2321208701, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXK2DGNPNRAM6YKJJDM3XDZUBVM7AVCNFSM6AAAAABNFCZKJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRRGIYDQNZQGE . You are receiving this because you authored the thread.Message ID: @.***>

[rerdavies]

@BorisSutin

More questions.

• can you access the NxM snapshot view (or list, TBD) from PiPedals main page, or are they only available in the snapshot view of the Setlist/Songs Snapshot views? Does there need to be a concept of snapshots for a presets independent of the setlists/songs/snapshots series of views? i.e should each preset have its own set of snapshots, independent and separate from the list of snapshots in a songs which is one click away from the Top Level page?

[BorisSutin]

If I understood your question correctly, the interface is usually always untied from the logic of the work. The main thing is that the service accepts commands from the client, so that from a mobile application or another client, it is possible to control the function independently. In fact, this is an add-on to the general service, like a utility for pedalboards. We need such an interface in which the user could choose what to use, switching through the setlist or switching through the list of pedalboards or switching songs. The list of pedalboards exists independently of the list of songs.

Snapshots (state or scenes) are always tied only to the pedalboard. They have no relation to the song. For example, such a situation. A cover band played a specific setlist of 10 songs. At the end of the performance, the audience asks to play another song, for example, zz top la grange. The guitarist must open the list of songs, find the artist zz top in the context search, select la grange in the list that opens, and the pedalboard associated with this song will be loaded into the device.

[rerdavies]

OK. I'm not getting it.

Let's take it as a given that all presets (pedalboards) get their own dedicated set of snapshots, which can be created and edited from the current top-level UI. I can (just barely) fit that into the current pipedal UI.

With that in hand, why doesn't the existing datastructure for banks and presets do everything you're asking for? With the understanding that:

Banks <-> Set Lists.
   +=  Presets <-> Songs
      +=   Snapshots <-> Snapshots.

You create a bank named "Setlist for Hamburg". You add pedalboards (presets in the current UI) to that bank, perhaps copying them from other banks, perhaps creating brand new ones., Each preset in the bank is given the name of a song. And each preset/song has a set of snapshots with user-selectable names. The sole difference is that songs in a set list are stored by value, not by reference (by ID), i.e. setlists cannot share the same instance of a song/pedalboard/preset.

Your "setlist" is my "bank". Your "song" is my "preset/pedalboard". Your snapshot is my snapshot. The datas structure is the same, except for the names.

I can see the need for a parallel UI to navigate that data structure that's more fit for purpose for performance use.

Let's provisionally call it a "Performance View" (probably not the name it will end up with, but good enough for now). The performance view gives a view of banks, and presets and snapshots, but arranges things in a way that changes can be made with a single click, and in a way that server state (snapshots particularly) has full affordance in the UI.

The top toolbar of the Performance View would look like this:

[X] < [name of the current setlist [V] > [X] <[Name of the current song [V]>

Or, using current terminology:

[X] < [name of the current bank[V] > [X] < [Name of the current preset [V] >

Where < and > are next and previous buttons, and [..... [V] are dropdown listboxes, [X]s are icons. If any of those selections are changed using MIDI controllers, the toolbar updates accordingly, but the user stays in the same view. So the toolbar not only provides selection, but also an affordance for the state of the server (makes the state of the server visible).

The rest of the view shows a 2x3 (3x2 in landscape) collection of boxes containing the names of snapshots. Could also be a listview, but the NxM boxes makes it absolutely clear what this is all about, I think. Users are limited to 6 snapshots per preset. Clicking on a box selects the snapshot. A menu on the left of the toolbar provides management functions:

Rename snapshot
Shuffle snapshots

Copy snapshot to... .... maybe others to be determined.

An edit button in each box, or a long press launches an editor for the snapshot. Same as the curent top-level view but structure is not editable. control values can be freely edited. The appbar for the edit view view is " <- Edit Snapshot [Name]

Plus minor revisions to the management UIs of banks and setlists that make it easier to copy presets (songs) between banks (setlists). Review the actual use cases for setlist/song management, and see what's missing.

What do you think?

[BorisSutin]

I think you have a lot of work ahead of you) Otherwise, everything seems to be correct. Good luck with the implementation and thanks for the work.

[rerdavies]

Published in v1.3.53. Fixed in v1.3.54 (hopefully)