i think that is what we are talking about, no?
and we are just working out the best place to put it right now.
i think imposing a descriptor format on every engine command, and pushing those descriptors through OSC, and into lua, is a lot of extra infrastructure that is brittle (in ways we might not foresee right now) and doesn’t accommodate a lot of more experimental structures.
(i’m emphatically not interested in recreating Audio Units, for example - way too prescriptive. if you try to accommodate a broader range of musical control structures you end up with something like LV2 - which has a lot of neat ideas and is super flexible, but also pretty inaccessible. an alternative version of norns would just be an LV2 host, solving many of these questions but requiring tons more work to implement DSP engines.)
what @jah has already done with the ack engine seems like a good template for an immediate pragmatic solution - the “discovery/descriptor” part is implemented in lua, alongside the engine, and just provides defaults for the existing parameter system in lua. it’s not as architecturally elegant as doing everything automagically in the engine API, and it requires the .sc and .lua components to be synchronized, but it’s a lot less work and more flexible - e.g. scripts can easily override or ignore the boilerplate as desired.
ok… well, this isn’t really compelling for me at this point. we want to work on cleaning up, extending and improving the core features for the norns device - not making it into a video synth (just yet), and not making the software work on hypothetical alternative hardware or on someone else’s product. if you want to do that it’s fine. if you want to, say, use a second screen for development (presumably with a usb-vga adapter), then i don’t see how that relates to supporting other outputs with the cairo drawing commands available to norns scripts.
sure. this sounds like its better done on the lua side to me. but it’s also a little vague what we’re talking about.
i’m assuming you want to say something like - “this script is designed to be used with a grid controller of at least MxN size - but it should work either with a monome TTY device or a MIDI device, and should seamlessly connect to one or the other when plugged.” ok cool - this sounds like a job for a (simple) adapter class in lua, and of course we would welcome such a contribution.
the matron C stack is about providing lower level connections. it’s simple. libevdev for hid, rawmidi for midi (and yes, as far as we can tell this supports multi-port devices just fine), libmonome for monome, OSC for whatever else.
the only device class that’s missing, in my opinion, is alternative TTY-based protocols. but this is such a vague category that i’m waiting for some actual use case to appear before worrying about it.
if it would be useful to pass more descriptor data to lua for each device class , that’s simple enough to do and doesn’t require some huge restructuring.
if you want to make the C device layer super smart and have the weaver layer be more abstracted, i guess i’d be curious to see what you come up with, but not sure i see the engineering advantages.
