|
|
Post by reductionist_earth_catalog on Dec 23, 2021 15:32:06 GMT
I had this idea for a stack of GRAINS modules connected to a single MIDI interface, all taking MIDI note on/off information from the MIDI interface. (Because sometimes I don’t like tuning my oscillators by hand).
Naively, I want to basically give the MIDI interface several thru ports, and connect those thru ports to GRAINS modules by modifying the GRAINS to take MIDI Rx on a pin of the microcontroller. On the wiki page for grains, the rough schematic seems to indicate that the microcontroller has unused pins (https://wiki.aemodular.com/pmwiki.php/AeManual/GRAINS)—is my reading of that correct? I saw there were a few empty thru-hole pads on the grains pcb that looked like they are connected to the microcontroller—does anyone know if these can be used?
This also would require modifying grains firmware of course. I was planning on using SoftwareSerial for that, but I would have to do more reading.
|
|
|
|
Post by pt3r on Dec 23, 2021 17:22:32 GMT
|
|
|
|
Post by reductionist_earth_catalog on Dec 23, 2021 18:32:39 GMT
I imagine I will probably make or buy a midi-cv interface at some point, but I was thinking of sending midi messages directly to Grains instead of first translating midi to cv and then sending cv to grains. So a bit different from the usual modular approach, but I like the idea because it seems like it would allow me to avoid manually tuning Grains (which I find tricky due to lack of a fine tune knob). It seems to me that the digital output on grains could then be used as a gate for associated envelopes, etc. furthermore, if I get this working, I can imagine microcontroller-based sequencer modules that send note on/off information directly via midi. It is of course less flexible in some ways than cv, but I could see it having other advantages. |
|
namke
wonkystuff
electronics and sound, what's not to like?!
Posts: 686
|
Post by namke on Dec 23, 2021 19:28:07 GMT
I imagine I will probably make or buy a midi-cv interface at some point, but I was thinking of sending midi messages directly to Grains instead of first translating midi to cv and then sending cv to grains. So a bit different from the usual modular approach, but I like the idea because it seems like it would allow me to avoid manually tuning Grains (which I find tricky due to lack of a fine tune knob). It seems to me that the digital output on grains could then be used as a gate for associated envelopes, etc. furthermore, if I get this working, I can imagine microcontroller-based sequencer modules that send note on/off information directly via midi. It is of course less flexible in some ways than cv, but I could see it having other advantages. This is an idea that I've been toying with for a while - have a 'MIDI demultiplexer' with one output per MIDI channel, and then a family of modules which would only need to decode stuff in 'omni' mode (either that or the demultiplexer also re-channels everything to channel 1). Still on the drawing board  |
|
|
|
Post by reductionist_earth_catalog on Dec 23, 2021 19:34:34 GMT
This is an idea that I've been toying with for a while - have a 'MIDI demultiplexer' with one output per MIDI channel, and then a family of modules which would only need to decode stuff in 'omni' mode (either that or the demultiplexer also re-channels everything to channel 1). Still on the drawing board That’s a cool idea—I was going to hardcode the midi channel for each grains in the code, but this is way more user-friendly—you could have output sockets for each individual midi channel and a dedicated input midi socket on the controlled module! |
|
namke
wonkystuff
electronics and sound, what's not to like?!
Posts: 686
|
Post by namke on Dec 23, 2021 19:57:15 GMT
This is an idea that I've been toying with for a while - have a 'MIDI demultiplexer' with one output per MIDI channel, and then a family of modules which would only need to decode stuff in 'omni' mode (either that or the demultiplexer also re-channels everything to channel 1). Still on the drawing board That’s a cool idea—I was going to hardcode the midi channel for each grains in the code, but this is way more user-friendly—you could have output sockets for each individual midi channel and a dedicated input midi socket on the controlled module! Yep, exactly  You could also build a sigle-channel MIDI-CV module and expand it to multiples; oscillators could also (potentially) have 'thru ports' to support polyphony too (e.g. any new notes come in whilst the current note is sounding just get forwarded to the thru port, to be handled by a second/third/whatever oscillator). Of course an oscillator module could in itself be polyphonic… |
|
namke
wonkystuff
electronics and sound, what's not to like?!
Posts: 686
|
Post by namke on Dec 23, 2021 19:58:27 GMT
… it's very definitely high on the wonkystuff 'to do' list, but we'll see in the new year whether I can summon up enough momentum!
|
|
|
|
Post by reductionist_earth_catalog on Dec 23, 2021 22:04:03 GMT
And I am still definitely an early beginner when it comes to electronics—since everything is running off the 5v and gnd of the ae modular power supply, I wouldn’t have ground loop issues as long as the midi input was onto-isolated, correct?
|
|
namke
wonkystuff
electronics and sound, what's not to like?!
Posts: 686
|
Post by namke on Dec 24, 2021 0:05:05 GMT
And I am still definitely an early beginner when it comes to electronics—since everything is running off the 5v and gnd of the ae modular power supply, I wouldn’t have ground loop issues as long as the midi input was onto-isolated, correct? Yep. I've done MIDI reception/processing stuff back in the 90s (with discrete logic!) and everything is pretty straightforward once you've got the output from the opto-isolator (ground loop issues are why there's an opto there at all of course). |
|
|
|
Post by reductionist_earth_catalog on Feb 18, 2022 18:14:11 GMT
|
|
|
|
Post by rodney on Feb 21, 2022 5:49:25 GMT
So, namke , you are thinking to have a MIDI bus running through the case (or at least an oscillator region of a case)? Having Rx, Tx and Gnd, could you use the existing Gnd on the bus? this could carry the MIDI clock that can be pulled out wherever it is needed. I don't like having MIDI clock on the system bus anyway, because it needs a divider module to make it usable, so it would make more sense to me to send the divided clock along the bus (which I sort-of do, after cutting the wire on the Bus CV, Gate and Clock from the master module  ) (detailed here forum.aemodular.com/thread/1147/repurposing-bus-cutting-wires) |
|
|
|
Post by rodney on Feb 21, 2022 6:21:36 GMT
I forget if it is possible to get Grains to handle USB MIDI input from its built-in USB port.
If it is doable, a USB hub and a bunch of USB cables would be fugly-but-effective. Alternatively,
If there is a spare input pin accessible on Grains, something like this:  To get a single MIDI out from an arduino, something like this would be fine. |
|
|
|
Post by rodney on Feb 21, 2022 6:56:37 GMT
... but, if you want to fan out to multiple MIDI outs from a single MIDI input, you'd need something like the MIDI input circuit above, then a transistor to crank up the juice so it can feed all the Grains units' MIDI inputs. ... but it should really only need one transitor to beef up the MIDI enough to drive a few Grains modules with MIDI in circuits.
|
|
|
|
Post by rodney on Feb 21, 2022 6:59:31 GMT
In this MIDI Shield project for Arduino, the MIDI out part could be repeated using the one transistor, as long as you don't overdo it.
|
|
|
|
Post by reductionist_earth_catalog on Feb 21, 2022 17:04:45 GMT
As it currently stands, my GRAINS modules are both connected to a USB hub, and I am sending them MIDI from a raspberry pi running multiple instances of ttyMIDI. I did take a peek at the PCB, and it looks like there are solder pads connected to arduino pins 11, 12, and 13, which I believe make up the SPI interface.
I think if I wanted to not use USB, I would just make my own grains modules. Then, I could connect rx/tx pins to the headers on the front of the module, but honestly USB is working fine. I am getting less noise than I expected, and later on I might migrate my raspberry pi setup to a headless Zero W connected to the USB power module so everything is sharing the same ground. Of course, then I would have to be more vigilant about the amps I have available in my case…
|
|
namke
wonkystuff
electronics and sound, what's not to like?!
Posts: 686
|
Post by namke on Feb 21, 2022 17:12:06 GMT
So, namke , you are thinking to have a MIDI bus running through the case (or at least an oscillator region of a case)? Having Rx, Tx and Gnd, could you use the existing Gnd on the bus? this could carry the MIDI clock that can be pulled out wherever it is needed. I don't like having MIDI clock on the system bus anyway, because it needs a divider module to make it usable, so it would make more sense to me to send the divided clock along the bus (which I sort-of do, after cutting the wire on the Bus CV, Gate and Clock from the master module ) (detailed here forum.aemodular.com/thread/1147/repurposing-bus-cutting-wires)No, not a MIDI bus, but a MIDI module which would demux each channel to its own pin (which would still be a serial data stream). There would be an optoisolator on its input as per MIDI 1.0 spec, but after that there's no need. The 'ecosystem' would then be something like a CV extractor which would take one of these demuxed serial streams and convert it to CV/Gate. Since the channel demuxing happens elsewhere, these modules can operate in OMNI mode; change channel by simply changing the connection to the MIDI demux module. There might be a poly CV/Gate module too, with perhaps an 'overflow' MIDI output which could then be patched to another etc. etc. Of course this opens up the possibility of an oscillator with a MIDI-stream input, perhaps polyphonic as well… |
|
|
|
Post by rodney on Feb 27, 2022 6:49:21 GMT
No, not a MIDI bus, but a MIDI module which would demux each channel to its own pin (which would still be a serial data stream). There would be an optoisolator on its input as per MIDI 1.0 spec, but after that there's no need. The 'ecosystem' would then be something like a CV extractor which would take one of these demuxed serial streams and convert it to CV/Gate. Since the channel demuxing happens elsewhere, these modules can operate in OMNI mode; change channel by simply changing the connection to the MIDI demux module. There might be a poly CV/Gate module too, with perhaps an 'overflow' MIDI output which could then be patched to another etc. etc. Of course this opens up the possibility of an oscillator with a MIDI-stream input, perhaps polyphonic as well… Another possibility would be a single-wire digital protocol of some sort (MIDI needs tx and rx, even for 'one-way' control) in order to keep with the jumper wire model of AE patching.
However, digital folk might argue that, once you get that far, you'd just have a bus and have invisible patch wires in software - maybe push-buttons with RGB-LEDs built in for each in or out terminal, so you hold down an output button then press any number of input buttons to route signals and/or controls to them? (they would automagickally pick a new random colour for each new connection)
|
|
|
|
Post by rodney on Feb 27, 2022 6:50:18 GMT
(lots of extra noise for the analog part of the system to deal with! )
|
|
|
|
Post by reductionist_earth_catalog on Jan 21, 2023 15:40:21 GMT
Just wanted to share where I am with Project GRAINSILO. I figure I would tie a few different threads from DIY and Programming back here, because this might be the best umbrella topic for my project. To summarize, I have a kind-of-working system where you patch AE gates and triggers into a Arduino gate-to-MIDI interface. That interface is connected to SuperCollider (in my case, via USB to a Pisound). SuperCollider patterns are triggered by the trigs/gates, and those patterns send MIDI noteOns (and noteOffs) to MIDI-controlled GRAINS modules via USB. Here is the thread describing my gate-to-midi converter, and here is the thread describing MIDI-controlled GRAINS. Here is a GitHub Gist with a SuperCollider example showing how the patterns are triggered with MIDI noteOns. The first 87 lines just set up all the MIDI connections. The patterns themselves are lines 96-131. The noteOn responders that clock the patterns from the gate-to-MIDI interface are lines 143-178. What this means is that I can clock patterns with the plethora of different trigger/gate-producing AE modules. I don't have to tune my oscillators manually, since they are MIDI-controlled. Using SuperCollider, I can create arbitrarily complicated patterns, and I don't have to have tons of sequencers and switches to do so. Potentially, I can also get a wider range out of each oscillator than 5 octaves, since I'm not relying on 5V V/oct CV inputs (though I haven't updated my GRAINS firmwares to do this yet). This was sort of inspired by things like the Monome teletype, where you trigger scripts with gates/triggers from Eurorack. So far, the whole system could be more stable. Sometimes my Pisound crashes if I leave all this running for a while. I would also like to understand the plumbing behind SuperCollider patterns, so I could make the SuperCollider code simpler or more concise. |
|
|
|
Post by reductionist_earth_catalog on Jan 21, 2023 22:58:27 GMT
On the online meetup today, I realized I should probably add a disclaimer to this thread, since these are experimental firmwares, and there is always a possibility they will brick your grains module, use at your own risk (see this AE Modular forum post for a description of the possible problem and solution: forum.aemodular.com/thread/1858/serialport-show-anymore-brick-grains). |
|
You could also build a sigle-channel MIDI-CV module and expand it to multiples; oscillators could also (potentially) have 'thru ports' to support polyphony too (e.g. any new notes come in whilst the current note is sounding just get forwarded to the thru port, to be handled by a second/third/whatever oscillator). Of course an oscillator module could in itself be polyphonic…
) (detailed here 
