Feature Requests #1
Description
Here is a list of features that have been requested. Please add more as needed:
[ ] Small button added on every jw bpatcher that will recall/set default.
This is easy enough to implement. Each jw.odot.* patcher initializes with a default state.
JK: Option 1: JW button or mechanism that receives o.preset’s CAPTURE (and all events other than delete preset), so it sends out its latest data on each o.preset Manager event - this way, someone doesn’t have to move the UI to capture JW data each time when pressing o.preset’s button.
Option 2: or o.additionalcapture could be stateful (it currently clears its memory every time the user captures a preset).
[ ] When o.preset manager writes a preset all JW objects should report their package without having to touch them.
This is already possible with the proper workflow. Already, the patchers' internal loadbang does this on startup and with each change to any of its parameters. However, this will not be captured while live-patching as the loadbang happens before signal is connected to the odot output. The solution might be to create a protected send in each module, say jw_omni, that is received by o.preset. Perhaps this should all be wrapped into a jw.odot.state abstraction that bridges to the o.preset world.
EC: In 201A we are using receive jw_odot as the global receive for JW abstractions.
[ ] jw.odot.matrix writes out bundle of the current state of the matrix
To preface, jw.odot.matrix is still unfinished. It still needs a way to be driven by line messages. I have prototyped this in testing, but it is prone to causing lags in the system, so I left that functionality out of the current version. For now, setting the object's global ramp time is as close as we can get. State reporting is possible, but slightly tricky given the nature of the abstraction. When given the 'dumpconnections' message, matrix~ will dump its current state in the form of a nested dictionary, which works only as long as that dictionary is defined. Probably, we need to do a translation to the odot world so this can be unified with o.preset, but it is still unclear to me as to the best way forward. All of this in the context of a patcher that writes itself, it is a back-burner project for sure.