Triple 16n faderbank controls using X,Y,Z

[XORadmin]

Understood, makes sense. What about a lua i2c interface to NerdSeq? It seems the ER-301 API for example is open source on Github: https://github.com/monome/crow/blob/main.../er301.lua

It might not be too hard to write one for NerdSeq if there was some spec on how different i2c signals could map to different results in NerdSeq?

EDIT: I guess the Teletype implementation of the SC* commands is also public and quite simple C code so doing a PR to add a NerdSeq library doesnt seem impossible although recompiling Teletype might be a bit of a drag (https://github.com/monome/teletype/blob/...ps/er301.c)

I don't really understand what you mean. Should I implement the lua engine in the NerdSEQ so it can process lua scripting that comes from an I2C port?
I guess not and it would be an imense of overload on the I2C port. As far as I can see lua is only used in the teletype source to describe the different I2C commands. But I did only a quick look over it and don't know anything about that yet. 

The question is rather how far should that go in the end. They are many hundreds of possible parameters in the NerdSEQ. It's not a ER301 or JF which got like 10 or less different parameters, which is of course easy to implement. 
And then we are only talking about I2C. 
That is one of the reasons the mappings are there, to not rely on a strict fixed connection for each midi or I2C or CV or whatever command/signal, but to be flexible with every incoming data and process it with any of the hundreds destinations regardless of the type of source. 

For sure I will not do any coding in the teletype code.

[flel]

I don't really understand what you mean. Should I implement the lua engine in the NerdSEQ so it can process lua scripting that comes from an I2C port?
I guess not and it would be an imense of overload on the I2C port. As far as I can see lua is only used in the teletype source to describe the different I2C commands. But I did only a quick look over it and don't know anything about that yet. 
The question is rather how far should that go in the end. They are many hundreds of possible parameters in the NerdSEQ. It's not a ER301 or JF which got like 10 or less different parameters, which is of course easy to implement. 
And then we are only talking about I2C. 
That is one of the reasons the mappings are there, to not rely on a strict fixed connection for each midi or I2C or CV or whatever command/signal, but to be flexible with every incoming data and process it with any of the hundreds destinations regardless of the type of source. 
For sure I will not do any coding in the teletype code.

So admittedly I am still learning and don't know very much yet, but here is my limited (and potentially not fully correct) understanding of this:

The TT is now out of production and has been superseded by Crow/Norns. Crow is a modular/computer interface that can be programmed using live Lua scripting via either Druid (a python-based command line tool in which one can pass commands to the modular) or Norns (a Raspberry pi-based controller that can be fed live-fed Lua code via a webserver or run stored scripts complete with user interface). Below is a pic of my setup, crow is the small 2hp module next to TT and Norns is the controller-like unit outside the case front right.

Most TT i2c interfaces (including the JF, 16n and ER-301) have been ported from C (in which TT was coded) to Lua for use with Crow. While the backend of crow/norns is also in C (and Supercollider), Lua is used extensively as a front-end scripting language. I could be wrong, but from my quick glance at the codebase all i2c interfaces are fully coded in Lua, which seems pretty straightforward. See e.g. these PRs as examples:
https://github.com/monome/crow/pull/434
https://github.com/monome/crow/pull/260

The question is rather how far should that go in the end. They are many hundreds of possible parameters in the NerdSEQ. It's not a ER301 or JF which got like 10 or less different parameters, which is of course easy to implement. 
And then we are only talking about I2C. 
That is one of the reasons the mappings are there, to not rely on a strict fixed connection for each midi or I2C or CV or whatever command/signal, but to be flexible with every incoming data and process it with any of the hundreds destinations regardless of the type of source. 
For sure I will not do any coding in the teletype code.

Have you ever thought of making (portions of) the NerdSeq source code open source? I think people (myself included) would be happy to poke around and suggest stuff. Anyway, writing a Lua interface for the NerdSeq might not be too difficult even if not as long as there is a clear specification on how different messages are mapped to NerdSeq parameters/commands? Take a side-by-side look for example at the i2c spec for Distings and the Lua interface:
- https://github.com/monome/crow/blob/main...isting.lua
- https://github.com/scanner-darkly/telety...CIFICATION
You can see quite simply how different messages are coded in the spec and in the code. If a similar list could be compiled for NerdSeq parameters (admittedly yes there are probably hundreds and way more complex than even distings) then maybe writing a Lua interface isn't that hard (just perhaps time-consuming).

[XORadmin]

I don't really understand what you mean. Should I implement the lua engine in the NerdSEQ so it can process lua scripting that comes from an I2C port?
I guess not and it would be an imense of overload on the I2C port. As far as I can see lua is only used in the teletype source to describe the different I2C commands. But I did only a quick look over it and don't know anything about that yet. 
The question is rather how far should that go in the end. They are many hundreds of possible parameters in the NerdSEQ. It's not a ER301 or JF which got like 10 or less different parameters, which is of course easy to implement. 
And then we are only talking about I2C. 
That is one of the reasons the mappings are there, to not rely on a strict fixed connection for each midi or I2C or CV or whatever command/signal, but to be flexible with every incoming data and process it with any of the hundreds destinations regardless of the type of source. 
For sure I will not do any coding in the teletype code.

So admittedly I am still learning and don't know very much yet, but here is my limited (and potentially not fully correct) understanding of this:

The TT is now out of production and has been superseded by Crow/Norns. Crow is a modular/computer interface that can be programmed using live Lua scripting via either Druid (a python-based command line tool in which one can pass commands to the modular) or Norns (a Raspberry pi-based controller that can be fed live-fed Lua code via a webserver or run stored scripts complete with user interface). Below is a pic of my setup, crow is the small 2hp module next to TT and Norns is the controller-like unit outside the case front right.

Most TT i2c interfaces (including the JF, 16n and ER-301) have been ported from C (in which TT was coded) to Lua for use with Crow. While the backend of crow/norns is also in C (and Supercollider), Lua is used extensively as a front-end scripting language. I could be wrong, but from my quick glance at the codebase all i2c interfaces are fully coded in Lua, which seems pretty straightforward. See e.g. these PRs as examples:
https://github.com/monome/crow/pull/434
https://github.com/monome/crow/pull/260

The question is rather how far should that go in the end. They are many hundreds of possible parameters in the NerdSEQ. It's not a ER301 or JF which got like 10 or less different parameters, which is of course easy to implement. 
And then we are only talking about I2C. 
That is one of the reasons the mappings are there, to not rely on a strict fixed connection for each midi or I2C or CV or whatever command/signal, but to be flexible with every incoming data and process it with any of the hundreds destinations regardless of the type of source. 
For sure I will not do any coding in the teletype code.

Have you ever thought of making (portions of) the NerdSeq source code open source? I think people (myself included) would be happy to poke around and suggest stuff. Anyway, writing a Lua interface for the NerdSeq might not be too difficult even if not as long as there is a clear specification on how different messages are mapped to NerdSeq parameters/commands? Take a side-by-side look for example at the i2c spec for Distings and the Lua interface:
- https://github.com/monome/crow/blob/main...isting.lua
- https://github.com/scanner-darkly/telety...CIFICATION
You can see quite simply how different messages are coded in the spec and in the code. If a similar list could be compiled for NerdSeq parameters (admittedly yes there are probably hundreds and way more complex than even distings) then maybe writing a Lua interface isn't that hard (just perhaps time-consuming).

I don't see any need to integrate LUA into the NerdSEQ to describe the different packets etc. There is no need for it and there is no benefit. And involving another compiler, toolchain, firmware overhead, worse debugging and so on are possible side-effects. This is stuff, not really made for real low-level systems (even though it can be used and run with them). 

The NerdSEQ will not be open sourced in the near future and probably not after that. Though I am still open for a NerdSEQ teletype integration where the Teletype part is of course a simple LUA description while in the NerdSEQ it would be a simple C description of the commands (but they are many many and it would need a long list of commands etc... you can use the mapping sources and destinations as an example and not everything is even in there yet). The question is though how many people would use it and for what? If it is just for this and that parameter then it is not really worth to put time into it since that is already possible with the mappings.

[flel]

The mappings are great. The only reason really is the limit on mapping rows, if one i2c port = one mapping row and you're trying to do tons of modulation there just aren't enough rows to do everything. E.g. I have a single 16n controlling like 64 different things (eg each fader sending CV to a different port depending on another variable) and that's reaching the mapping limit and not leaving any space for other fun modulation

[XORadmin]

The mappings are great. The only reason really is the limit on mapping rows, if one i2c port = one mapping row and you're trying to do tons of modulation there just aren't enough rows to do everything. E.g. I have a single 16n controlling like 64 different things (eg each fader sending CV to a different port depending on another variable) and that's reaching the mapping limit and not leaving any space for other fun modulation

I do understand. But that is all we got with the mappings and there will not be more.

I also think a Teletype I2C implementation would affect only very few people.  For me it would be more an implementation for my inner-Nerd.

[flel]

Yep understood. If "Merge out" forwards all commands to bus B it would already be huge, because one could have e.g. 50/100 ports used in the mapping screen and the other 50ish forwarded and directly in the ER301 without needing to assign mapping rows for them. Hopefully that won't be difficult to patch/fix!