#41

relevant libmonome code for opening a monome on POSIX systems:

1 Like
#42

For my own implementation I did not need to run that command beforehand but itā€™s probable that the pyserial module is handling all of that in the background. The only parameter I needed to declare in my code was the baud rate.

I never did button-mashing stress tests on it, though, but it seems to hold up with moderate button usage (say 2-3 buttons pressed/depressed at at time). And it seems to work consistently across my Windows desktop, Fedora laptop, and Raspberry Pi with Raspbian.

#43

Just bought a RP3 B and have a grid kit sat waiting. Iā€™m hoping I can pull of some simple music fun with it

2 Likes
#44

this seems to be a readily available solution for getting 2 channels in/out of a pi:

http://canada.newark.com/wolfson-microelectronics/cirrus-logic-audio-card/hd-audio-card-wm5102-stereo-rpi/dp/84X8125?CMP=KNC-GCA-GEN-SKU-WOLFSON_MICROELECTRONICS&gclid=COSTlOTd1c4CFVFcfgodLqQPbA&mckv=sNhtcfBBo_dc|pcrid|42812471753|plid||kword|cirrus%20logic%20audio%20card|match|p

could be a manageable, affordable route to deploy something like @askbreā€™s molisam software on ARM (for those of us that missed out on belaā€™s kickstarter). I read one blog post that claims they got a low-latency (1/2 ms) audio setup cooking along these linesā€¦

#45

http://blokas.io this looks interesting

3 Likes
#46

yah - looks like another good option - couple of built-in midi ports is a nice bonus! Of course the midi circuit is totally trivial to hijack pi/bbb UART - the thing that seems really tricky for more ā€˜casualā€™ DIYers (barring mad kernel-hacking skillz) is hooking any olā€™ i2s DAC into alsa.

Anyone know of a linux kernel module or something that works like ā€˜blank codecā€™ for one of these little arm boards? I.e input/output i2s clocks & signals on the relevant pins, leaving any i2c configuration to hand-rolled driver in userspace? How would one set samplerate & pcm data-format with such a thing? (assuming something actually exists - I googled couple of times and came up empty-handed)

Actually quick and dirty i2c configuration of most audio chips can even be done quite effectively using shell-scripts leveraging tools i2detect, i2cset & i2cset. Iā€™ve done quite a bit of hacking around/bodging with one of these usb->i2s bridges - but obviously latency is nasty for music purpose because USB. stereo audio i/o on a pi gets a lot more interesting if you can also switch off the DACā€™s DC offset correction like these awesome little things http://www.expert-sleepers.co.uk/es3.html

#47

Is anyone starting serialoscd automatically as part of their Raspberry Pi boot sequence?

Iā€™ve tried calling serialoscd from /etc/rc.local but Iā€™m having problems with the orientation of my grid when I do that (itā€™s 180 degrees out)

If I start serialoscd manually, then there is no problem.

Perhaps running from /etc/rc.local means serialoscd fires too early access the config file, or something?

Any suggestions would be most welcome.

regards,

Mark

#48

did you try this ermina` suggestion earlier on this post?

#49

hmmm sounds like I will also run into this once things are running well enough to think about moving from my dev laptop to embededdedā€¦
EDIT:
no! I wonā€™t because I rolled my own serial driver for monome in lisp ha!

maybe itā€™s possible to have /etc/rc.local run an auxilliary script in the background, where the first line of aux script is sleep 20. Like this:

/etc/rc.local :
/home/rick/bin/run-serialoscd.sh &

/home/rick/bin/run-serialoscd.sh:
/usr/bin/sleep 20
/usr/local/bin/serialoscd

havenā€™t actually tried this myself - quick enough to suck it and seeā€¦

#50

serialosc will store per-grid configuration in the home directory ($XDG_CONFIG_HOME/serialosc, to be specific) of whatever user is running it. furthermore, because Iā€™m lazy, the config file is only written when the monome is unplugged.

if anybody needs the write-on-shutdown behaviour, I could add it with some delay, or somebody could submit a pull request with atexit() or a signal handler or similar.

#51

Thanks Will,

write-on-shutdown is not an issue for me - it seemed to be perhaps a timing issue on boot up, and in general there was weirdness on the raspberry pi - as if the rotation degrees werenā€™t really being properly interpreted as I was only getting 180 degree rotations, regardless of whether I specified 90 or 180, but because Iā€™m on fairly deprecated hardware (40h logic boards), and rolling my own grid code in any case, itā€™s not worth trying to fix at the serialosc layer (even if that is the issue) - Iā€™ve just coded my own rotation handling functions within the python script Iā€™m using.

so with regard to the boot up issue, I just reset the config for one of the grids to have a 0 degree rotation and adjusted within my own script, and that has dealt with the problem.

I probably still need to look at some kind of ā€œhardeningā€ for serialoscd in terms of detecting if it crashes and automatically rebooting, but Iā€™m hoping that once Iā€™m no longer hacking on the sequencer script itself, then serialoscd crashes will become a thing of the past.

time will tell :slight_smile:

#52

detecting if it crashes and automatically rebooting, but Iā€™m hoping that once Iā€™m no longer hacking on the sequencer script itself, then serialoscd crashes will become a thing of the past.

do you have any more details about those crashes?

#53

cheers @wrl for pointing O_NOCTTY flag is the correct way to open serial terminals- turns out my insane stty incantation fails sometimes when youā€™re trying to use beaglebone UART as a midi port. Kind of means I have to use a bit more cffi dark magic to read raw serial terminals from common lisp rather than using common lispā€™s binary file primitives, but that is a small price to pay for things actually workingā€¦ thanks again - you are my UNIX hero!

EDIT:
Thought Iā€™d nailed down broken midi/uart ports after reboot, but no such luckā€¦

EDIT:
weeeee! finally got all the midi stuff working cleanly on boot but yea the code that handles uart setup is really inelegant - a dark incomprehensible mass of stty commands and arcane cffi calls! So finally I have a headless system booting cleanly and repeatably into a boomerang-synched step-sequencer. Feels like a good achievement, however rotten is some of the plumbing!

Definitely need to start documenting these techniques a bit more systematically in a more sane format than frantic lines postsā€¦

#54

Hi @wrl. What Iā€™ve noticed is that I sometimes get a segmentation fault when plugging in my grid. Bear in mind that I have two 40h boards in a case with a small hub connecting them to a Raspberry Pi, so my assumption is that

a) this is a strange setup

b) having two grids connect close together in time because of being connected to a hub might cause issues.

After a crash it seems to take a few cycles of connecting and disconnecting the grids before serialoscd will start without a seg fault.

The issue is a bit hard to reproduce. I havenā€™t looked into any logs to see what might be revealed there, but will see what I can collect next time it happens.

#55

gnarly. can you get me a backtrace?

#56

Having a bit of a problem here. When a grid is plugged into an RPi and just about any LEDs light up, the board starts making noise that resembles capacitor noise like the one described in the 2015 grid noise fix thread.

With no LEDs lit the noise goes away. Itā€™s clearly the RPi board, not the grid. Did anybody else notice such behaviour? Is there anything that can be done to fix it? :thinking:

#57

Iā€™ve not run into that problem, so Iā€™m not much help.

Iā€™ve run two 64 grids from a raspberry pi - Iā€™ve connected them via a powered hub, and directly to the pi.

I think I did check that the power supply Iā€™m using for the pi had amps to spare, so that things didnā€™t get flaky once the grid started to pull power, though it should be limited to USB specs in any case.

are you running a 128 grid off the pi? maybe thereā€™s an issue with running the larger grid directly from the pi itself instead via a powered hub?

apologies if youā€™ve thought of all these things alreadyā€¦

#58

Yeah, running a 128 grid kit. Powered hub is not an option, unfortunately, because I intend to run this entire setup from a portable phone charger battery (and with a battery powered speaker), so Iā€™d prefer to keep the number of devices and wires to a minimum :slight_smile:

#59

if its a pi 3 then you definitely need the full 2.5A available. iā€™ve also found that itā€™s happier with a hair over 5v for some reason - the official supply is 5.1v.

i havenā€™t actually tried two grids but did find 5.1V @2.5A to be necessary to reliably run a 2016 m128, a custom soundcard based on cirrus cs4272, and a USB trackball.

and have found the effects of insufficient power to be potentially pretty bad, like fsck errors leading to filesystem corruption.

ā€¦ and just to be clear, i know that power consumption has been discussed further up in the thread. but that was 2015. pi3 takes a lot more than pi2 (4 cores!)

1 Like
#60

Hey all Iā€™m a bit late to the party but have found this thread extremely helpful for what Iā€™m trying to do.

Unfortunately Serialosc is not working properly on my raspberry pi 2.
When I tried to run it after installing it would say ā€œcommand not foundā€ so I followed rknLAā€™s instructions to use the 1.4 stable release commit and this helped a little, but now serialoscd is only working intermittedly and never creating the config file that I need.

Does anyone know how to fix this and get the config file?