#21

Thanks. I should do more tests based on these informations. From my experience, with the 1.8k resistors it is also preventing the ER-301 from booting. The Olimex manual strongly recommends 4.7k resistors on the i2c bus. This needs to be tested once again, I need to confirm that :slight_smile:

1 Like
#22

I just want to say; this is a really really REALLY cool project. I have been looking at the OD store every day, looking for shipments to start again, and matching my Polyend Tracker and norns with a 301 via OSC sounds divine. Not To mention potentially translating a Twister Fighter and Arc to OSC commands and further control over the 301 would be a paradigm shift on top of the 301 to begin with.

Thanks for taking up this cool project and I truly hope you get all your questions answered, because you work could be a game changer for a lot of folks.

1 Like
#23

Thanks ! :blush:

I hope not to disappoint anyone if the latency is not that great for example. I’ll work on the Node.js part and we will quickly see if the concept is functional and reliable or not. I also need to have more control over the 301, that’s why I started this, the 16 inputs are not always enough. A solution like this could also be cool for euro setups with just a 301 in a Pod for example, mobile Eurorack. At this point I cannot guarantee anything but I’m glad I got the Pi to talk to the 301.

By the way, during my “researches” I’ve found that the Olimex board the Er-301 uses has two Ethernet ports… they are not physically present but…

1 Like
#24

I mean, at the rate COVID is going (not to mention the amount of interest I’ve seen on the OD boards for the unit) it’ll be about 4 to 6 months before I get one to try this out with. Guess that gives minds greater than mine a chance to really dig in and see if this works. If it does, I can imagine a lot of cool, bonkers things that could be done with Max/MSP and this. Haha

1 Like
#25

Ah yes, loads of people seem to wait eagerly for the OD shop to re-open and I can understand that, I hope Brian has been assembling a lot of 301 while the UPS/Fedex system is blocked in Japan . For ultra reliable connection from Max etc there’s Crow. Once again I cannot guarantee that a wireless connection will be perfect :smiley: My goal here is just to put the 301 solo in a USB powered pod, no additional cables, controlling some faders and start/stop some loopers from my phone or iPad. But there are a lot of possibilities once the the RPi sits in the case, is connected to the module via I2c. The node-red interface remains accessible from a web browser for additional tweaking etc

2 Likes
#26

just catching up on this thread - really cool project, thank you for the commitment to make it work!

this could be super useful for other followers, especially those that have many parameters to control. and could have some generative/sequencing scripts running right on the device itself.

2 Likes
#27

That’s true. I really haven’t dug much in to crow and max. I just finished the PCB portion of an arc build, and am in the process of machining/cutting out the rest of the parts. Using Max and crow will be really exciting then, especially with the TXo.

But yeah, I keep thinking ‘maybe I’ll just get a Japanese address/shipping service to get the 301,” but keep realizing that it’s still a 4 week lead time and then we’re looking at FedEx shipping cost and receiver fees! :wink:

But dang, even something like Fugue machine on an iPad, or other types of programs then sending to the 301 could be wicked cool.

I’ll be keeping an eye on this project, for sure. I’ve got a PiZero from an old AI/wireless video project just kinda chilling in a box somewhere.

2 Likes
#28

Thank you @scanner_darkly :blush: it’s made possible thanks to your work, all the I2c commands, the ii protocol etc. This week I‘ve had the chance to finally understand how the I2c protocol works. I’m far from mastering it and as mentioned earlier it would be helpful to have an oscilloscope for troubleshooting, but it seems to work so…

Yes, absolutely some devices have so many accessible parametersand even with TT it’s sometimes difficult to set something up to control all of these easily (the TXo can be a cool (4) oscillator(s) module but it’s difficult to set it up, loads of lines needed within TT) Some param won’t need ultra low latency to be set, I wouldn’t recommend Wireless OSC to I2c for a step sequencer for example but who knows? Node.js is quite fast after all.

The node-red environment is also easily accessible and super simple, it would be a good place for writing JS functions, recall presets on various modules, I don’t know :man_shrugging: Everything’s possible. One thing i know Is that I really want to add Midi BLE to this setup, and… there’s a “node” for that :slight_smile:

Edit: there’s a major downside to this project, the RPi is a leader too :confused: If it takes place in the bus with TT or Crow, it’ll probably want to drive it. I’m not sure how it will react with other leaders, I have read that a multi leader bus is entirely possible but it might need ee and software adjustments to work.

1 Like
#29

Let’s hope the Pi Zero is fast enough, I’ll do some tests soon, especially the wireless part of it, otherwise we might have to use a larger device, it would not be great because the plan is also to reduce the cost at max but I’m planning to make a kind of “hat”, the size of a RPi zero, directly pluggable to a free 12v header in the Eurorack case maybe (? I need to borrow some parts of a schematic) it’s probably too soon for planning that though :wink: Some people will prefer a 1u with a USB port (for connecting a Leapmotion or Midi device). I’ll try to work on the code in the meantime… first, let’s see if it’s reliable/stable and fast :slight_smile:

P.s: designing a small external circuit was absolutely not part of the plan but since it seems to be needed (for various reasons like clock stretching support, possibility to use various pull up resistors values etc) why not add 12v to 5v conversion to it instead of “dangerously” powering the pi from the 5v rail with two wires?

image
image1536×2048 649 KB

I have something like this in mind, the components are not valid, sorry for the poor drawing :grimacing:

1 Like
#30

Yet another bump in the road, the ER-301 responds only to the TR_Pulse command. I’m trying to troubleshoot this issue.

TR_Pulse is the only command that has only one argument - Port -

Option 1 - at some point the module doesn’t Ack anymore and the additional bytes are lost. Unlikely, but who knows ?

Option 2 - The issue is linked to the integer type conversion happening within Node.js (see below). Probably.

TXo responds well to a command with multiple args like TR (port + state), it also responds well to CV. The integer type conversion within Node.js is a bit weird right now, I’m investigating. The CV out is at 0v for an int 0 sent from Max, 10v for 127 and 0v again at 255. It should receive a signed integer and be at 10v for a value of 16383, am I right ? Funny because the TXo handles this quite well (probably not as precise as a signed integer but it works) But the 301 doesn’t like that and expects only a S16.

I hope I can solve that soon, I’ll speak with the maintainer of the I2c node.

Expect some delay :wink:

#31

it should be exactly the same for txo CV and er-301 CV - the only difference is the i2c address.

both expect the value to be a signed int16, most significant byte followed by the least significant byte. what you describe leads me to believe that you’re only sending one byte and txo is more forgiving and uses 0 for LSB, while er-301 doesn’t.

CV values are based on the fact that tt has 14 bit DACs so 16384 maps to 10V.

1 Like
#32

Ahh, this would explain why TXo responds and not the 301, interesting. I was afraid this could be another hardware issue.

In that case, it’s linked to the “node”. It is supposed to send two bytes, but some users reported some issues in the past and I’m not sure it’s totally reliable at the moment. I’m exploring it’s code right now and have started talking with the new maintainer of the repo.
Hopefully, this can be fixed easily.
Thanks :slight_smile:

#33

to clarify, not sure this is actually the case, just my guess based on what you described

1 Like
#34

I’d highly recommend a logic analyzer so you can figure out where the issue arises. Here’s an open-source powered option for only $20 https://www.sparkfun.com/products/15033. I think i’ll get one myself! A serious upgrade from my scope.

2 Likes
#35

Yes, you’re right, it’s needed. I’ve just ordered a similar product AZDelivery Logic Analyser , the reviews are good and it’s only 10€. It’s compatible with Saleae. I thought a Logic Analyzer would cost 500€

1 Like
#36

Ok, it’s working now, there’s no hardware issue. As a matter of fact, the Node-red I2c module has a bug, I managed to find a temporary workaround but I need to fix this in the code. The logic analyzer will be helpful for that.

Yes there’s a small latency in this demo, using an ad-hoc network would probably improve that.

5 Likes
#37

Dang, that’s gotta feel GOOD. Love it when a plan comes together. Congrats

2 Likes
#38

The Logic Analyzer was very helpful in understanding the problem.
I realized I was sending the “value” as one byte instead of two : :smirk: noob… But easily fixed and everything’s fine now.

What next ?

  • Implementing the N and CV values ? By the way, I realize that the range on TT and Txo goes from -16384 to 16383 whereas the 301 receives signed int16 (-32768 to 32767) and converts everything to 32-bit floats. I’m wondering if I should clamp the values to this range for the 301 too (and let users set the gain on the module).

  • Moving the list of commands for each module in separate files (the list of TXo commands is long, right now only a couple of common commands are implemented…)

  • Setting the scene for other i2c capable modules ?

  • Packing the flow as a “project” for easier sharing, version control, dependencies management.

  • Midi IN ? how should it be mapped ? Very subjective…I could add a the possibility to personalize the mapping in a separate JSON file.

  • Finding a name for the project and posting it to GitHub with install instructions or install script.

3 Likes
#39

-16384 to 16384 maps to -10…10V range in teletype world, and it should be the same for er-301. does it actually produce higher value on er-301 if you send a higher value?

0…120 note range is 10 octaves, so it maps to 0…16384 range. so your calculation is:

pitch = note * 16384 / 120

but you might want to have an option to transpose too - especially since different devices will map to different octaves.

1 Like
#40

Yes it does. Assigning an SC.CV to a bipolar VCA and setting the gain to 1.0, the 301 will go from -2.0 to 2.0 (for an int of 32767) Not a big deal, I can divide the integer by two in my function and the precision will still remain totally fine. + there is a “gain” setting on the 301.

Thanks :wink: Actually I meant: Does it make sense to map/hardcode midi notes and continuous controllers to some specific SC.CV/ SC.TR combinations. There was no consensus in this thread
hence the possibility to use a JSON file for personalizing the mapping maybe. We’ll see.

OSC is easier and more flexible /module/unit/command/port/ value /er301/1/cv_set/1/ $1