Device abstraction

[jsmcnair]

I have a suggestion that could help with the following issues:

#9
#6
#3

How about a "device profile" type of abstraction that allows to configure one or more device profiles. A device profile would include:

• Name
• Device
• Port
• (arbitrarily) 8 CC mappings

Devices would be stored as an array in the JSON file and deserialised into a list such that a node could reference a device profile index (and mapped CC index). A change in the underlying hardware configuration would only require updating the device profiles.

This improves the UX in the following ways:

• Users can associate a friendly name for a set of properties relating to a device. For instance, if I have two synths on the same MIDI device using different ports I can refer to the synths by name, rather than having to remember the device and port associated with it.
• Selecting the the properties I need to send messages from a node to a specific MIDI device becomes as easy as selecting the device profile.
• A reconfiguration of the underlying hardware, e.g. different computer, rearranging studio, etc. only requires updating the device profiles and not every individual node that uses it.
• Remembering the last used device becomes less of a concern as there are fewer permutations to setup per node.

I'm not sure where the device profiles would best be stored. It seems like it would make sense to be a separate configuration to the node storage, as its more related to the underlying system than an individual canvas. Signls could look for a default filename of profiles.json, but allow specifying the filename. If no filename is given and the default does not exist, Signls could create it and populate it with some sensible defaults.

[xaviergodart]

Thanks a lot for the detailed suggestion!
It would be a very complete approach to solve the problem.

However, my opinion on this is that it would add a certain amount of complexity to the codebase, for something that:

1. could be handled in a simpler way, at least for now
2. could be handled by external patching software

I think I'll go with solutions described here and here first. And see how that works.

Also, I'll soon have a new setup with pipewire. That will allow me to investigate the pipewire issue #8. That may also help with midi workflow issues.

[jsmcnair]

Ok, yeah I think that's fair enough if you anticipate it being used in a plugin host type situation.

Can you give me an example of how you use it in Carla, so I can have a play with that? I know Carla can handle routing but how does it handle Signls not being a plugin?

My preferred way to use it, in that case, would be to have it as a virtual MIDI device on the system and route everything via BitWig. That way BitWig can handle all the routing. However, I think it would need to be capable of receiving transport messages so that they start at the same time.

[xaviergodart]

Ok, yeah I think that's fair enough if you anticipate it being used in a plugin host type situation.

Can you give me an example of how you use it in Carla, so I can have a play with that? I know Carla can handle routing but how does it handle Signls not being a plugin?

What I usually do is this:

• I connect the default midi through output to Carla in jack
  
• I add instruments and I use a midi channel filter to map midi channel to specific instruments
  

I also use it with external synths.

My preferred way to use it, in that case, would be to have it as a virtual MIDI device on the system and route everything via BitWig. That way BitWig can handle all the routing. However, I think it would need to be capable of receiving transport messages so that they start at the same time.

That would be a good way to use it. Not sure you would need transport messages if you only use bitwig as an instrument rack. But transport messages would be nice to have. Signls already sends clock messages.

A simple TUI plugin host would a super cool project though (like this one for example), I have that in mind for quite some time, but I always imagined this as a separate project.
Basically something where you can add up to 16 instruments and that can be controllable only via midi. And it would be nice if it comes with some default instruments like synths and drums. Basically a headless (without a sequencer) Elektron box if you're familiar with them.

[xaviergodart]

#9, #6 and #3 are now fixed. Closing this for now but feel free to reopen.