Performance view (version 1)

[AndreaDelSignore]

Hi,

I’m experimenting with the concept of a performance view.

I’ve read that someone also request for it here in the forum and also it’s something that is missing from mod UI in my opinion.

I’ve coded a first rough implemetation that is functional, but still preliminary and I want to publish here to get some feedback.

My requirements are:

1. Should be used during performances or rehearsals
2. Desktop and mobile touch friendly
3. Minimal impact on the existing UI

Screenshots

Mobile version

Access to performance view with and icon on the menù:

The first “page” is the snapshot view where you can change the current snapshot

Vertical swipe to access all the settings of the plugins in the pedalboard

Desktop version

Screencast

Mobile screencast

TODO

1. Better icons, fix to layouts, more polish (done)
2. Better mobile gestures (good enough)
3. Desktop mode: hilight the selected effect (done)
4. Mod page: add a new page after snapshots with all the port assigned to mod knob & buttons (not easy)
5. Select which plugins add to the performance view (done)
6. Add a button to show always all plugins: useful to make quick parameters adjustment (done)
7. Reorder plugins with drag and drop (done)
8. Plugin labeling (done)

Ok, it’s all for now and it’s late

Andrea

[edit: added todo]

[dreamer]

Oooh this is a really interesting concept!

I’m a little confused on how the plugin view works. It just scrolls through each of the plugins consecutively?
This may get difficult when you have duplicate plugins or simply a whole lot of them on a pedalboard.

Although conceptually I think it’s still powerful (especially combined with the parameter groups!)

Really nice out of the box thinking and adding a whole new UX on top of the existing system!

[AndreaDelSignore]

Thanks @dreamer, I’ve just added some notes on the TODO, yesterday was very late

@dreamer

I’m a little confused on how the plugin view works. It just scrolls through each of the plugins consecutively?
This may get difficult when you have duplicate plugins or simply a whole lot of them on a pedalboard.

This problem can be mitigated by selecting and reordering the plugins to show in the view

I’m also thinking if we can allow to assign a label to the plugins in the pedalboard.

Anyway the code is not yet ready and I like the concept, the view is also useful to quick change a plugin parameter during rehearsal or the performance.

[dreamer]

I was thinking the same of labeling. Not sure if this has come up before on the forums.

[AndreaDelSignore]

Yes, may be the labeling could be done on this view by clicking or double clicking or long tap on the plugin name.

I don’t know the implications on the pedalboard file format though

[jetztgradnet]

This is awesome!

Even if the code is not ready, would you mind describing a bit how you went about expanding the Mod GUI and how you hooked this into the code running in the MOD device?

[AndreaDelSignore]

Oh you are asking to much for several reasons:

1. I didn’t grap all the code and the architecture of mod-ui
2. I’m not so expert with all the UI frontend tecnoligy used, but I’ve +30 years of professional experience in programming
3. My english is… bleah

General approach

Anyway it took me more than 2 days to write the module and this was my approach:

1. Read the code to get an idea of the library and frameworks were used in the frontend:
   a. HTML+Javascript
   b. JQuery+UI
   c. Mustache
   d. Less with Grunt
2. Study a bit of everything
3. Start to modify the codebase and see what happens:
   a. Try to add an icon on the menu and open a new page (I searched for similar code: pedalboard library, bank manager and file manager)
   b. Write somenthing similiar and hook on the UI
   c. Try to reuse the plugin settings dialog for most of the UI (that was very hard at first)
4. Follow the conventions used, even those that I dont’ like

Tecnical notes

To be more specific all the UI is included in the index.html with the orchestration of the Desktop (desktop.js) class, Host (host.js) class, Pedalboard (pedalboard.js) and several other files to glue the html code + the mustache templates + the js behaviour.

The mustache templates are in the folder ‘include’ and are processed and served by the python backend in a single js file with all the content stored on a js opbject so it can be used by mustache in this way:

div.innerHTML = Mustache.render(TEMPLATES.plugin, plugin_data);

The css styling is done with less except for pedals.css.

I can go futher but I don’t know if this is the right place

[LievenDV]

Ah very nice for us live performers!
Curious where this will lead to!

[AndreaDelSignore]

I pushed the sources here: GitHub - sejerpz/mod-ui at features/performance-view

@jetztgradnet this is the relevant commit: Add performance view to mod-ui · sejerpz/mod-ui@783524d · GitHub

If there is someone with graphics foo I need two icons:

1. for the perfomance menù
2. for the snapshot item in the list view

Let’s see where this will lead, but sure I’ve a long term plan…

[Ant]

This could be like the phone apps for controlling in ear monitors on stage. Assign controls you want live to big buttons. Love it.

[Zavorra]

This is a great idea!

[AndreaDelSignore]

Not yet there, you can’t assign arbitrary controls but just choose which plugin goes to that screen.

It’s already useful to modify parameters on plugin basis and also to quick adjust an arbitrary pedalboard plugin parameter

Of course you can also select snapshots.

[AndreaDelSignore]

Just an update on the development: the first version of the mod-ui “modding” is completed.

Now I’ll wait eventually for some MOD feedback and I’ll just polish the patches fix bug etc…

I really like also to find a way to “release” it and let less tech people try it, but I don’t really know how to do.

Sources are here: GitHub - sejerpz/mod-ui at devel

This is what I implemented:

• Port group extension, but in order to be really useful this requires to update plugin ttl files and add group annotations. Who will/can do this?
• Performance view
• Plugin labeling e.g. give your plugin a custom name.

Performance view

The concept is great and I’m planning a version 2 with more functions for now my requirements were:

1. the possibility to change plugin parameters like you will do with a physical stombox or the dawrf itself
2. the possibility to change an arbitrary plugin parameter e.g. during a soundcheck or rehearsal
3. bonus: load a snapshot

Mobile version:

Desktop version:

Customizations

Click on the top right gear to enable design mode where you can:

• Choose which pedalboard plugins see in the view
• Change the order with drag & drop
• Change the label of every plugin to differentiate two or more instances of the plugin
• Save the pedalboard

Plugin labeling can also be done in the standard settings dialog on the pedalboard constructor:

That’s all for now, my next step will be in a total different area of my beloved Darf stay tuned

[Abotte]

That’s really impressive, such a serious enhancement for those who use the web-ui while performing.

I was wondering if ther’s a way to estimate the added footprint on Dwarf and, assuming that these improvements will eat some cpu cycle, if we should expect an increased workload also when we go headless.

Thanks a lot for your efforts!

[dreamer]

This hardly costs any additional processing. They are mostly cosmetic features with some minor metadata additions.

All of the heavy lifting is done by your web browser.

[AndreaDelSignore]

I confirm, just some more metadata scanning at startup everything else is done on the browser with javascript.

[pilal]

I just tested it on a raspberry pi with a 7" touch display and I love it. I’m not sure I feel brave enough to push it to my dwarf though. Do you have any safety advice for those who would like to install this on a mod device?

[AndreaDelSignore]

Good to hear that it works for you, thanks!

Before going too tecnical: I’ll release all these changes (and some more I’m still developing) in a custom dwarf image when I feel they will be ready for a broad testing

I think that’s too early to push on the dwarf, I still haven’t done myself, but from my understanding it can be done safely because in any case you can reflash the original firmware image without any problem.

These are the step required:

1. Compile the native libmod_utils.so present in the mod-ui/utils with the dwarf toolchain (the same you will use for developing a plugin)
2. deploy the .so file in the same location of the previous one: /usr/lib/python3.4/site-packages/modtools/libmod_utils.so
3. run the mod-deploy.sh script

if you want you can take a backup of the original files (see the script for details) present on these folders:

1. /usr/lib/python3.4/site-packages/modtools/
2. /usr/lib/python3.4/site-packages/mod/
3. /usr/share/mod/html/

[fer]

I still don’t know exactly how to do step 1. But for the Dwarf I suppose the step 3 should be done from a mod-ui based on branch hotfix-1.13 for firmware 1.13 or plugin-store…

[AndreaDelSignore]

You can’t mix the new mod-ui with an old libmod_utils, it won’t work.

Read here: Open Images - MOD Wiki

“Compatible binaries can be built using mod-plugin-builder”

So you have to setup an environment like the one used for building a plugin and from there compile the libmod_utils.so

In order to compile it’s enough to run

“make -C utils”

from the mod-ui repos.