sorry, my last post was excessively snarky in tone and unhelpful. i’ll rephrase…
illucia controllers are TTY usb serial devices, closely analogous to monome controllers. this is a common transport mechanism for custom controllers using ad-hoc protocols. i don’t know how many illuca devices exist in the wild, so i would treat them as simply one instance of a DIY device.
norns (or indeed pretty much any computer) can speak to TTY devices directly, without need of a separate OSC bridging process.
norns also has native support for HID devices (anything that libusb recognizes and MIDI devices (anyhting that ALSA recognizes) so these are good, obvious, easy choices for custom controllers.
(OSC bridging is definitely an option, via Processing or whatever, and maybe the quickest way to get some new thing working, but it strikes me as an unecessary waste of resources - UDP buffers are not unlimited and the system already generates a lot of local OSC traffic - in addition to being fiddly.)
currently, norns attempts to treat TTY devices as monome controllers and open them with libmonome. this is not really sufficient, and we will probably want to provide some fallback behavior(s) for “generic” TTY communication. this is not hard to implement, but is another case where the primary use case is DIY / custom situations, and it seems best to treat such cases as they arise in practice, instead of trying to predict them beforehand.
if there are a significant number of people using the illuca protocol, then my recommendation would be to refactor the (minimal) logic from the illuca-connect Processing patch into a C module, and add it as a device profile to norns. but i don’t seriously expect this to be the case.
i am a proponent of using existing protocols for custom devices. if HID or MIDI are unfeasible and TTY is preferred, then i think the monome serial protocol is a logical choice.
if libmonome needs to be expanded to accomodate other/arbitrary device profiles, that can be done. but there are a lot of benefits to a little bit of standardization, and the monome protocol is well-supported (apple driver woes notwithstanding- that’s unrelated to protocol considerations.)
as for the actual question:
it is not very specific. sure, you could easily make norns programs for which “re-patching” has some meaning “in the box.” but it only has 2 physical channels of I/O, so as a patch bay it’s pretty limited.
on that note,
sorry, the headphone output is not independent of the main outputs, it is just an additional amplification stage. (soundcard is 2 in / 2 out, not 2 in / 4 out.)
that was a misconception; for the record, i didn’t add a “vocoder” (applies the spectral envelope of one sound to another sound, using either a discrete filterbank or STFT and cepstral smoothing), i added an engine that does various kinds of spectral magnitude manipulation using a phase vocoder. could be made to be a kind of vocoder i guess, though IMHO a “classic” vocoder is better done with a discrete filterbank (and it’s an easy exercise in supercollider.)
mostly what i like to do with that is to capture snapshots of incoming magnitude spectra (often from percussion or voice) and use them like oscillators, with different sources of phase (live input, white noise.) i quickly added this to norns to perform in a friend’s piece (“ten tinted silences” by syrinx)
i really wanted to ask for examples of code to dissect
any chance we could see the engine for one of the apps?
soon enough (next week.)
all lua
