Live patching mode

ok, this one is very much purple sky… and doubt it’ll be viable…
but given now my two top FR (knob catchup / auto load) are implemented in 2.1.3 :heart: , thought Id reach for the sky :slight_smile:

also, perhaps even if we dont get the full request, perhaps some simplified version may be possible .. I’ll discuss this later in post.

Live patching mode

so the idea of this one is simple (but not to implement),
when we have the MM connected via MM to the desktop, and VCV running, the patch on the MM is synchronised to the patch running within VCV.
so as you make changes to the patch, they ‘automatically’ update on the MM.

this includes :
a) patch structure - adding modules, adding cables
b) parameters values.

why is this so useful?

simply put, it leverages the advantages ease of patching on the desktop, but allows us to hear the changes within out physical racks. it also means we can see the real load on the MM as we patch, and so optimise ‘in place’.

an example:
imagine we are creating a simple patch with clouds on the mm, where we are sourcing the audio in from other modules in our eurorack.
we can having this patched in VCV, and as we change parameters on the cloud module we can hear the changes from our eurorack on the input source it is using.

I see this ‘mode’ being as simple as ‘enabling’ on the vcv mm module.


ofc, in theory this could be done with continually copying the patch to the MM.
so one could argue a simplified solution here is to have a autosave/copy from vcv to mm.

though I suspect this will need some ‘optimising’ as its pretty slow.
a crc could be used to see if a copy is necessary, but still the copy is slow.

it be better if, the wifi protocol was extended, so allow more fined grain actions e.g. add module, add patch cable, update parameter.

as I said, at the beginning, I recognise this could be a lot (prohibitive) amount of dev effort,
but wanted to describe an ‘ideal integrated workflow’.

simplification

I do think, however, whilst full patching would be ideal, you could get 75% of the benefits with a simplified form which simply updates parameters.
the workflow would be create the patch (modules/cables) then save it to MM (as we do not)
then the ‘live’ patching would just be just for parameter updates.

why is this the ‘best’ bit?
well there is a lot of fine tuning of parameters on some modules, and this can be laborious, doing this with the mouse on vcv is so much quicker.

perhaps this could be done via an osc protocol, as there have been other FR for parameter modification via osc !?

what does it miss out on ?
cpu load balancing… if you can ‘live add’ modules its be much easer to see the cpu load build up, as you build the patch out.
though if we have a quick one click ‘save’ button, I guess this would alleviate this.

this simplified form is actually how Axoloti worked,
the desktop editor would save/compile the patch when you went ‘live’
during live you could only change the parameter values.
I found this workflow really powerful :slight_smile:
(but ofc, many did want the full fat implementation ;))


overall, I think changes in this area could really allow us to leverage the use of the wifi more,
and allow us to take advantage of the synergy between vcv on the mm and desktop.

again, may be a bit to radical a change, but sometimes discussing pie in the sky ideas can lead to variations that can achieve some of the same goals.

2 Likes

If that was possible one day it would change everything.
In fact it would give you a complete new product for free.

if we ever see the ability added to be able to trigger that ‘send patch to mm via wifi’ button via a keyboard shortcut in the hub in vcv, one could get a bit faster updating of their work from laptop to mm. not nearly as simple/easy as automatic live updating as proposed above but would still maybe help speed things up. and at that point there’d probably be a way to script, via autohotkey or some other app like it, so that if any change is made in the vcv patch, send X keyboard shortcut

On a Mac you could add that keyboard shortcut using a utility like Keyboard Maestro and a “click on found image” action. Looks like AutoHotKey would do the same on Windows.

But I don’t think you could get a trigger every time you make a change in VCV, and in any case you’d have to reload the patch manually on the Meta each time.

auto refresh has been in for a bit now:

crude idea but: with autohotkey, X(or whatever you want) keyboard shortcut could be executed with any left mouse release - ‘LButton Up::Send {X}, Return’. so if a cable/connection is made via drag drop, the shortcut would get sent as soon as the cable is made. the same would work when moving a knob/clicking a button. would be easy to script in blockers, such as keyboard shortcut doesn’t get sent when whatever modifier key is held, or a script to on/off toggle via another keystroke. not a perfect solution but could still maybe work ok! provided we see the ability to map a keyboard shortcut to that wifi button however

some prev chatter about it here:

1 Like

using the rack api, you can determine this…

so, iirc, there is not an event you can take for module::add,
since you need the module pointer to register for module::onAdd()

however, you could periodically check the modules that are present in the rack, against the list you expect… this would be a very low cpu operation, as module all have a unique id (uint)

for all other events, e.g module remove. parameter change, port changes (aka cable) there are events.

as for auto-save, the rack does also track a ‘dirty/save’ state.
though, its likely any tiny change will cause this, so its likely you would want to do this more as a auto save after N seconds.

however, again, you could try to reduce the size/impact of that changes sent over wifi by doing differential events.

finally, another hook that may be possible is to use the racks history (used for undo/redo) as this also maintains a list of all changes occurring.
though I suspect this is a little more difficult in practice, esp when the user starts doing undo/redos- I think this might create some nasty edge cases.

overall, I do believe technically its possible (otherwise I wouldn’t have created the FR :wink: )
however, like most things, the ‘devils in the detail’ and without at least prototyping / testing the above a little - its hard to say if it’d really work one way or another.

also, as I clearly stated in the OP, Im not ‘minimising’ the effort it would take.

whilst the 4ms vcv metamodule does currently traverse the rack, it does not do this on live events… and similarly it just uses one wifi ‘event’ to save a patch file, whereas this would need a bunch of new events.

as I said, I think an interesting way to test this in theory ‘as a first step’ would be to do the parameter change event. this is useful in itself, but is a good (potential) stepping stone to other events.

Just to be clear, I was talking about how much could be done with user-level scripting technologies like Keyboard Maestro. Obviously you could do much more at the level of the VCV module code.