Pattern Library / Solenoid / Arduino?

RandColors · January 22, 2020, 3:32pm

Hi everyone,
I would love to start using controlled solenoids to make rithmic patterns.

I was wondering if anyone had expirience in making rithmic patterns using solenoids via arduino(or similar microcontroller) and if yes,
is there some code, tutorials or other materials about what I’m looking for?

Thanks in advance.
Best

PS: I found a project similar to what I would love to do (made in SC):
https://vimeo.com/99983152

ZeCraum · January 22, 2020, 9:52pm

You can find may stuff on Fredrik Olofsson GitHub:

https://redfrik.github.io/udk00-Audiovisual_Programming/

If you find some straightfoward solution for you problem, could you please post it here ?

RandColors · January 25, 2020, 2:35pm

Thanks for the reply, I’m checking your folders.
As soon as I find something useful, it will be my pleasure to share.

RandColors · January 29, 2020, 8:21am

…It will be updated…

If you guys don’t mind I just put here some reminders and thoughts about these days of learning.

I’m on :
Windows 7 home premium
SC 3.9.3

windows // I Need to check it later …

there is no serial port in the current version of supercollider for windows. to get around that problem you can run this small relay program in Processing together with this sc code. it is also possible to use puredata, python or maxmsp - basically any program that has both a serial port and opensoundcontrol objects.

if it’s true : use Processing and libraries like a bridge from sc to arduino … check it soon.

1) arduino and the sc serial port
General understanding of the serial port…
http://doc.sccode.org/Classes/SerialPort.html

Retrieve an array of available devices represented as String: Strings. On macOS and Linux, this list is obtained using a number of regular expression rules on files in the /dev/ directory. On Windows, this is obtained using a registry key. The matching rules are designed to be identical to that of the Arduino IDE.

For backward compatibility, if SerialPort.devicePattern is not nil, SerialPort.devicePattern.pathMatch is returned instead of the default behavior.

2) actuators (leds, solenoids, motors etc)

to send osc commands from supercollider to processing look at supercolliderToProcessing.pde and supercolliderToProcessing.scd

Hardware

jamshark70 · January 29, 2020, 9:49am

That should not be true anymore – you might have heard that from an out of date source.

github.com/supercollider/supercollider

Windows support for SerialPort

supercollider:3.10 ← supercollider:topic/serialport

opened 02:21AM - 24 Jun 18 UTC

mossheim

+757 -570

This PR adds Windows support for SerialPort and reworks the entire SerialPort cl…ass. Fixes #1008. Based most of this off @timblechmann 's prior work. Since we are now introducing this feature on a new platform, I thought this would be a good time to update the API/behavior a bit. I'm pretty sure I've done this in a non-breaking way for sane usage. The main changes are: - deprecated `cleanupAll`, no longer needed (see below) - deprecated timeout arguments to `put` and `putAll` - this just seems like bad design to me. `put` will fail if there is an error writing; I don't think it's a good idea to go into an infinite loop trying to write at that point. - internally, use `isOpen` variable instead of the dataptr directly to determine open status (makes shutdown simpler) - remove the default `doneAction` - in general I think we're trying to cut down on overbearing posts. - reworked shutdown procedure When `close` is triggered, a complex sequence of events happens: 1. The C++ port is closed and the SerialPort object is marked as closed. The C++ port's read thread waits on the global sclang execution lock to execute `prDoneAction` 2. The SC thread running `close` eventually yields, allowing the SerialPort's `prDoneAction` to run on a separate thread 3. That `prDoneAction` causes a deferred call to `prCleanup`. At this point, _not_ deferring would lead to a crash, because the C++ object's destructor needs its read thread to join, which would mean we are trying to join a thread from that thread itself - deadlock. This SC thread yields. 4. `prCleanup` sets the dataptr to nil and destroys the C++ object, and the read thread can now safely join. I don't know if there's a simpler way to do it, probably so, but this seems dead clear and doesn't potentially leak memory like the previous implementation did (AFAICT). It also means that the entire machinery of cleanup can be handled from the front by just `close` alone. Having separate user facing methods for `close` and `cleanup` was IMO unnecessary baggage. Also included are tests for SerialPort. Unfortunately, I tried but was unable to find a programmatic way to run these tests on Windows; I would appreciate some manual testing from Windows users! It would also be delightful to know if this compiles on RPi. Quick progress checklist: - [ ] Discuss modernization/changes to interface - [ ] Test on Windows - [ ] Check on RPi

Apparently this was merged about a year ago, into 3.10. 3.10.4 was just released so it should have the new feature.

If you know where you picked up the hearsay about no SerialPort in Windows, you might go back and let the author know.

hjh