Linux -MFX Signal chain editor application

Started by szszoke, October 17, 2021, 02:12:40 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

szszoke

Hello!

A few years ago I got introduced to the world of modelling amplifiers, multi-effect processors and guitar synthesizers.

Since then I was bugged by the fact that they all have their own PC applications that don't support Linux.

After a while I found FxFloorboard and I used it with my BOSS Katana amplifier.

I since then got myself a GT-1000CORE and I sadly couldn't use FxFloorboard anymore.

After a while I decided that I could start a project that would achieve something like FxFloorboard but it would be modular and would make adding support for new devices easier.

I started writing down some things and I would like your opinions (good or bad).

Everything is very high level at this point. I was using my GT-1000CORE as a base but I was trying to define everything as generic as I could.

In the end my aim is to have something that is cross platform and can replace Tone Studio entirely.

(Continued in next reply)

szszoke

Signal Chain Editor

Signal Chain Editor (SCE for short) is an application that can be configured as an editor for digital multi-effect units.

Digital multi-effect unit

In this context, a digital multi-effect unit (unit from now on) is defined as an electronic device that implements a series of audio effects and one or more signal chains.

A signal chain is the collection of logical blocks (blocks from now on) which represent an effect or signal coming from/going to a physical connector.

A block can have one or many inputs, one or many outputs, or both.

The output of a block connects to the input of a subsequent block.

A signal chain always starts with a block representing the dry audio signal and ends with block representing the wet audio signal.

Any number of digital multi-effect units can be supported (in theory) regardless of brand or maker.

Supporting different units

Configuration that is specific for a unit is stored in a JSON file. These JSON files will be referred to as blueprints.

A blueprint contains information about the signal chain and blocks.

Signal chain

A unit can implement one or more signal chains, each with their own set of blocks.

A blueprint contains information about the number of signal chains implemented by a unit and about all the blocks that can be placed on the given signal chain.

Blocks

Each block must have a set of properties defined:


  • Name
  • Unique identifier
  • Number of inputs
  • Number of outputs
  • Channel configuration for each input/output (mono or stereo)
  • Whether the block can be bypassed
  • Whether the block can be moved within the chain
  • Properties that can be changed by the user
Signal chain state

The order of blocks and the values of the user-editable properties represent the signal chain state.

The signal chain state is stored in a generic format (generic state from now on) that has the same schema regardless of the unit.

A special adapter application (adapter from now on) is used to convert the generic state to a format that is supported by the unit (unit state from now on) and vice versa.

Synchronizing generic state with unit state

Whenever an user-editable property is changed, the adapter receives the full generic state and the portion that is changed.

The adapter is entirely in charge whether to send the full state to the unit or just send the portion that is changed.

When the generic state is written to a unit with the purpose of saving it as a preset, the adapter always sends the full state.

szszoke

I am fully aware that this will be a large undertaking and I'm also aware I will have to refine my collection of definitions into something more coherent, but it has to start somewhere and this is it.

gumtown

#3
I admire your enthusiasm  :)
But in reality, things are a bit different and a lot more complex.
Each device has a different method of dealing with the chain and effects, even with similar Boss devices, each model requires a complete re-write of the code to work with the different structures.

The FxFloorBoard project is open source, and the source code is available to use/reuse for other projects.
The SY-1000 FloorBoard editor would be the most similar to the GT-1000/GT-1000 Core,
here is a link to the site and the source code if you want to have a look at it.
site = https://sourceforge.net/projects/sy1000floorboard/files/SY1000FloorBoard/
source code bundle = https://sourceforge.net/projects/sy1000floorboard/files/SY1000FloorBoard/SY-1000FloorBoard_source_code_20210809.zip/download

and this requires the Qt5 Integrated Development Environment (IDE) which the open source version is free from
use the Qt5.12 offline installer (win, mac, or linux) this has everything required to design/build/run applications in C++ Qt
https://www.qt.io/offline-installers
Free "GR-55 FloorBoard" editor software from https://sourceforge.net/projects/grfloorboard/

gumtown

Attached is a code portion of the SY-1000 editor signal chain 'drag'n'drop' and re-organizing of blocks, the GT-1000 will be very similar.

Here is the sysx code section for the signal chain
00 01 02 03 04 18 05 18 10 18 06 18 07 0E 0A 18 00 01 02 08 03 09 0F 0B 18 0C 0D 11 12 13 14 15 16 17

the first 4 bytes are the 4 inputs, which these can be organized to any order (SY-1000 only).
the remaining are the chain block layout, the "18" are chain events, such as combiners, and end of level markers.
Other items require logic to be used, if the Sub out and main out blocks are 'combined stereo" they must be moved together.
If the chain branch divide block is moved, all the attached A and B patch blocks and the combiner must also move.
The GT-1000 will use similar methods.
Free "GR-55 FloorBoard" editor software from https://sourceforge.net/projects/grfloorboard/

szszoke

Quote from: gumtown on October 17, 2021, 02:35:08 PM
I admire your enthusiasm  :)
But in reality, things are a bit different and a lot more complex.
Each device has a different method of dealing with the chain and effects, even with similar Boss devices, each model requires a complete re-write of the code to work with the different structures.

The FxFloorBoard project is open source, and the source code is available to use/reuse for other projects.
The SY-1000 FloorBoard editor would be the most similar to the GT-1000/GT-1000 Core,
here is a link to the site and the source code if you want to have a look at it.
site = https://sourceforge.net/projects/sy1000floorboard/files/SY1000FloorBoard/
source code bundle = https://sourceforge.net/projects/sy1000floorboard/files/SY1000FloorBoard/SY-1000FloorBoard_source_code_20210809.zip/download

and this requires the Qt5 Integrated Development Environment (IDE) which the open source version is free from
use the Qt5.12 offline installer (win, mac, or linux) this has everything required to design/build/run applications in C++ Qt
https://www.qt.io/offline-installers

Thank you!

I actually looked at the source code of some of the FxFloorboards and it does indeed look like all the units are their own thing.

I will be focusing on separating the UI state from the underlying device state as much as possible.

The reason why I think this might work is because regardless of how the memory is structured in any given device, visually, the editing flow is quite similar.

There are inputs, there are blocks with one or many inputs/outputs and they can be rearranged to a certain degree.

Implementing this flow would be the responsibility of the UI and the UI state would be stored in a generic fashion.

My plan is to use key-value pairs for properties. Then I would be able to store for example that the FX1 block has the compressor effect selected, and the attack property of the FX1 block is 50.

This is all theory right now, but I don't see why the UI would need to care about what the actual device is.

I am planning to abstract away all the device specific stuff in the adapters.

That means each device would have its own adapter. The adapter eats the JSON made by the UI and spits out SysEx messages that are specific to a single device.

I suppose this would be similar to your tool that can convert patches between different devices.

What I haven't figured out yet is to have a way to describe restrictions for the signal chain.

Some things can be inferred, like a block can only be moved between two other blocks if it has both an input and an output, but this might not be true all the time.

And what about blocks like a divider/mixer pair. I know that on the GT-1000CORE they are always connected with each other, but what if some other device will let you have an input/output unconnected?

I'm thinking that initially I would build a tool that can be configured to support the GT-1000CORE and then when I add support to a new device, I will see if the UI needs to be extended.

If not - awesome! I can just follow the recipe of the GT-1000CORE and write an adapter that handles the communication with the device.

If yes then I will have to see if I can modify an existing behavior to support the new device while supporting the new one or I need to write something new.

Again, my hope is that because the actual editing flow of selecting blocks, moving them to a different position and/or changing their properties is the same or similar between different devices, the UI itself can stay generic and the rest can be handled via device-specific adapters.

szszoke

Quote from: gumtown on October 17, 2021, 02:58:37 PM
Attached is a code portion of the SY-1000 editor signal chain 'drag'n'drop' and re-organizing of blocks, the GT-1000 will be very similar.

Here is the sysx code section for the signal chain
00 01 02 03 04 18 05 18 10 18 06 18 07 0E 0A 18 00 01 02 08 03 09 0F 0B 18 0C 0D 11 12 13 14 15 16 17

the first 4 bytes are the 4 inputs, which these can be organized to any order (SY-1000 only).
the remaining are the chain block layout, the "18" are chain events, such as combiners, and end of level markers.
Other items require logic to be used, if the Sub out and main out blocks are 'combined stereo" they must be moved together.
If the chain branch divide block is moved, all the attached A and B patch blocks and the combiner must also move.
The GT-1000 will use similar methods.

Thank you!

This will be useful when I need to write the adapter for the GT-1000CORE.

szszoke

One more thing to figure out is if I should start with the editor that can output a JSON object containing a generic representation of the signal chain or the adapter that could take a handwritten JSON file and convert it into SysEx that is specific to GT-1000CORE.

szszoke

I didn't make much progress here besides some general testing but it seems that there is now a MIDI implementation document for the GT-1000CORE.

There might have been one already, but I don't remember.

The point is that when I eventually start doing more serious work, I should have an easier time.