i don’t have a DTR but the build seems fairly straightforward… looking forward to seeing what develops in this thread…
DTR here as well… but haven’t spent much time with it lately. The apps that accompany the unit are pretty fantastic. I had plans to create a “tape-loop-box” with the DTR and @Rodrigo’s Karma Max plugin… but never got around to it. Still think that would be a pretty cool project.
So - working on the midi repatcher, I’ve found that there is a problem with the way the illucia sends signals from its output jacks to its input jacks. It polls the jacks cyclically and presumably transmits the signal values at the polling frequency. But this means that the values stutter, so to speak. I’m a bit stuck trying to figure out how to resolve this issue. Basically I need to debounce the input signals in max. The change object looks promising - but I’m chasing my tail. Any ideas?
OK, to kick off this conversation, here’s a little something I cooked up this morning: a patch to control the vavdo synths with the illucia. It’s not perfect because the actual vavdo controller has 5 buttons, so I had to compromise by using the bottom switch on the illucia as the central button (button 3 on the vavdo). Should be pretty self-explanatory, just wiggle and click. The vavdo controller also has 6 leds - not sure what to do about that. But for the rest it works quite smoothly. Enjoy!
vavdo_illucia.maxpat (22.6 KB)
@myecholalia points out that the vavdo website is down - if anyone wants vavdo S I’m happy to share. Just pm me with your email, it’s too big to upload here.
cool! just noticed that the vavdo website is currently disabled.
are you aware of any other sources to download the s synth?
or maybe it would be ok for us to upload it here?
DTR still in a box so nothing to contribute on the patch front yet. But I do have a question…
What OS, processing and illucia connect versions are you using your DTR with?
I could get it running fine and well on OS10.8.5 but try as I might OS10.6.8 success evades me. I did have some issues regarding what version of processing was used when I initially got the DTR and have a feeling that might be the issue with the earlier OS but it’s been a while.
My working setup is OS10.8.5 with processing v2.1.1 and illucia connect v1(1)
I have experienced flakiness with 10.10.1 (I think). I discovered by trial and error that: it will only connect on the second try, the first time you connect it after a reboot, and sometimes afterwards as well; I have to disconnect the device physically after disconnecting or it won’t connect again; it will never reconnect if I have to force the connect app to quit.
So, after booting, run connect, quit it and then run it again.
If you disconnect, make sure to unplug and reconnect the device physically before running connect again.
That’s my experience, anyway. It doesn’t get more anecdotal than this
I have more, but I’ve got to walk the dog now.
This is so cool! Thinking of building a DTR myself after seeing it in the other topic and the bom/software being open. Did anyone made one DIY?
Would love being able to use the patch bay especially in combination with Overtone/Supercollider. After a bit of research I realised the current implementation is more like for a patch bay between apps just passing on OSC messages. @strettara’s described value stutters would render it unusable for audio rate or smooth lfos? Did somebody already try to make a fork which send the connect/disconnect of jacks as OSC? That would be more flexible although state would need to be maintained by the consuming software as well then.
DOH I just found out about /dtr/JackIsPatched/
. Does it also communicate which connection is being made?
I haven’t made a DTR diy but it doesn’t look too bad to do.
As far as I know OSC isn’t designed for audio rate use and I’m pretty certain the DTR wasn’t really designed with this in mind anyway. I know when it first was introduced a few people questioned if they could use it as a patchbay for their modular synths. Which would make the DTR die!
As for the dtr/JackIsPatched question – yes, pretty certain you can get that information (it’s been a while since I have been able to use my DTR so my memory is a little hazy). Maybe check the Max DTR objects - they should help.
i stumbled upon the dtr last night while looking if anyone ever did an “OSC patchbay”.
I have a project (for the next year or so) to build a sort of “in the box” modular.
Think of each module as a two-parts thing:
1/ a chuck+csound application, with patch points and controls.
2/ a physical interface based on the illucia dtr principle.
Thus i would have the power and immediacy of turning knobs and patching cables, with the adaptability and the low cost of software.
I’m just starting to imagine the project but it seems largely doable.
Did anyone follow a similar road ?
Was exactly thinking the same but then for Overtone. Shouldn’t be too hard!
Yay for more overtone/clojure folks here
Overtone + DTR sounds super fun. I shouldn’t have slept on that sale.
I’m glad I found this thread (from here: Concept - Hardware Breakout Box for virtual modular?)
I took inspiration from Illucia and built a little box to play with. I didn’t have a Teensy++ on hand so I’m using a ‘pro micro’ board. It has fewer pins so I have fewer controls. At least it will give me a chance to play with the idea.
Thanks for the inspiration,
Jimmy
^^
Hi Chris!
Nice to see the DTR creator here
Bumping this old thread to talk about norns/illucia development—seemed more appropriate here than in one of the norns topics.
comments from @zebra:
currently, norns attempts to treat TTY devices as monome controllers and open them with libmonome.
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.
Another option is to modify the illucia firmware so it speaks the monome serial protocol rather than its own. I think this is a relatively easy path to implement, but there are some squishy decisions.
The 4 buttons can be modeled as keys with LEDs, the 4 switches can be modeled as 4 keys without LEDs, the patchbay could even by modeled as 120 keys (on/off for whether each unique pair is connected or not.) The 16-bit potentiometer values can each use two analog 8-bit analog inputs.
But what should the device report its size as? 1x4? 2x4? 32x4? How should it fill out the device info structures and what should the serial number look like? Would it be any easier for a Lua app to distinguish from grid/arc/illucia using the monome serial protocol vs. distinguishing them because they use different protocol drivers?
No norns here but it would be cool if people wanted to use their DTR with it.
I’d be happy if I could get Illucia connect working consistently on any computer at the moment because it decided to stop a while ago for some reason!
i have a working fates since yesterday and an illucia that i’d love to use with it !
I’ll have to find a way to use both together, preferably with keeping the firmware intact so the device can navigate seemlessly between laptop and fates. I have yet to dive into this and see if programming non-skills are sufficient, but in any way i’d like to help this happen.
I had this problem once and it was the small usb cable that goes from the external socket to the teensy that had been slightly knocked out of the teensy. Reseating it solved the problem!
Also at one point i tried to bypass the processing “driver” by reimplementing it in chuck/pd and i noticed that there is some sort of “goodbye handshake” sent from the processing driver to the illucia on closing illuciaConnect. If this is not done correctly the device takes several attempts to work on subsequent connections.
Otherwise i still have to write an instrument that makes a performative use of the patchbay. (I tend to use the illucia over other controllers as soon as i need a few switches and knobs in a single box).