Raspberry Pi 3 build, MDA Drum make picoloop freeze.

[lysergik]

Hello,
As said in the documentation I made a build from the debian makefile, on my raspberry pi 3 running the latest raspbian lite image. It compiled well, it launched well, it played well sound with almost all the synth, as the only exception is MDA Drum. When the sequencer play a MDA Drum step, it freezes. On the terminal windows running picoloop, everything stop, like if the clock crashes or is stuck and cannot play the sound.
I've tried different picoloop tag, 0.74d, 0.76c, 0.77a, 0,77b, 0.77c and 0,77d. Every build as the same bug. (I've also notice that 0.77c and 0.77d won't allow me to choose sound card or midi out/in as well on the RPI as on my Linux Mint laptop).
I'll try to compile and run picoloop on a desktop image of raspbian, maybe it will allow MDA Drum to play sound. If it won't work, I think the problem should come from the RPI storage reading speed, which as mentioned in the documentation could mess with .ds extension reading.
Still I'm not 100% sure of what is going on, if you could give me some light on MDA Drum dependencies, storage reading speed needed for the .ds file or any MDA Drum debuging tips it would be welcomed.
In last resort I would maybe try to use the rpi 1 build to see if it works(if MDA Drum is supported on this build.)

EDIT:
I've just tested on a desktop image of raspbian strecht, and i got the exact same probleme, with the 0.77b build. The console print the path to the MDA Drum patch directory, it says which step is playing, and then it froze, I've noticed also that when it happen the cpu tend to go way up in speed, and more specifically on a single core. Running at a strange 102-103% of cpu on a single core !
The thing is that the .ds file are in the directory /patch/MDADrum, but for some reason the synth goes wild, maybe latency, maybe a missed function call in the code or even something messing with libpthread on that synth, but it's very strange.
By the way I've build de RPI version, works perfectly, but it's not mean't to support all the synth so it's not the option I wished for.

[yoyz]

Hi lysergik,

That sound like a real bug !
I remember that the code works fine on a my linux box x86_64.
The code produced on the raspberry ( arm version ) is maybe buggy...

Could you launch it on the raspberry pi with "gdb".
$ gdb ./PatternPlayer_debian_Rtaudio
(gdb) r
Then when the code hang, type CTRL-C on the terminal, then
(gdb) bt
#0 0x00007ffff60236ad in poll () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007ffff43bb150 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2 0x00007ffff43bcc0f in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007ffff43bcd81 in xcb_wait_for_reply64 () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4 0x00007ffff583b018 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff5836b1d in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ffff7862c4a in SDL_UpdateRect () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#7 0x00007ffff7862e66 in SDL_Flip () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#8 0x00005555555a69b0 in seq () at PatternPlayer.cpp:4070
#9 0x0000555555570347 in main (argc=, argv=) at PatternPlayer.cpp:4354

It may help to have a first idea.
I have a raspberry pi 2 at home, but it's not installed if I remember, so it will give me a first idea.

Thanks,

[lysergik]

Hello,
Thanks to be that quick, so I've executed the gdb command as described and got this result(it's a screenshot):
https://mega.nz/#!x9BzhBrS!5XLNxFcjdaTgtX_gO31_JeEJXkzonQ-SuexEwW4h7rQ
So it seem that something goes wrong with glibc, if we look at :
/sysdeps/unix/syscall-template.S: No such file or directory.
I've began to look up forum thread with similar debug message and some say that this directory is needed when the compilation is done, but I haven't understood well it's functions and why it's missing on RPI 3(and maybe more generally on raspbian), and not on a regular x86 system. And also why it calls it only on MDA Drum and no other synth is quite weird too.

EDIT: I've just found that thread on the raspbian forum:
https://www.raspberrypi.org/forums/viewtopic.php?t=157048
They got almost the same problem that I have except it's with gstreamer, but like picoloop gstreamer does use glibc, and also lot of audio stuff(here's gstreamer depencies list https://gstreamer.freedesktop.org/documentation/frequently-asked-questions/dependencies.html)
Someone on that thread fixed their problem with this line in terminal:
raspivid -t 0 -h 640 -w 480 -fps 30 -hf -b 1000000 -o -| gst-launch-1.0 -v ximagesrc use-damage=false xname=/usr/lib/torcs/torcs-bin ! videoconvert ! videoscale ! video/x-raw,width=480,height=640 ! vp8enc ! rtpvp8pay ! udpsink host=52.88.76.93 port=5100
I don't think it should work for the picoloop bug, but do you think setting resolution to 640x480, at a 30 FPS rate, could be a way to fix the picoloop freeze ?
If it's the case I could almost try something with the xrandr comand to set at this resolution and framerate. And then run picoloop.

EDIT 2:
Well, the only way I could explained it's that there's a problem with value of SDL-Delay(delay); in PatternPlayer.cpp, at the line said by dbg:
// Here is the while (1) { loop } of the application
int seq()
{
AudioMixer & am=AE.getAudioMixer();
int cty=SEQ.getCurrentTrackY();
int ctx=SEQ.getCurrentTrackX();
int step=SEQ.getPatternSequencer(cty).getStep();
int oldstep=0;
int i=0;
int delay=1;
int t=0;
int running=1;
int nbcb; // current nb audio callback
int last_nbcb; // number of occurence of AudioEngine callback before changing step
am.setAudioVolume(DEFAULT_VOLUME);

dirty_graphic=1;

DPRINTF("PatternPlayer::seq()");

init_monomixer_and_machine();
// Init all track to the current step, step0 in this particular case
for (i=0;i<TRACK_MAX;i++)
seq_update_track(i);

refresh_pecursor();
init_and_setup_midi();

DPRINTF("openAudio start streaming");
AE.startAudio();

seq_update_by_step_next=1;
seq_update_by_step();
while (quit!=1 || running==1)
{
cty=SEQ.getCurrentTrackY();
ctx=SEQ.getCurrentTrackX();
#ifdef SDL_AUDIO
SDL_LockAudio();
handle_key();
SDL_UnlockAudio();
#else
handle_key();
#endif
// We give the processor to other thread to avoid spinning
SDL_Delay(delay);
seq_update_multiple_time_by_step();`

This value could be too short/long, and it make nanosleep freeze.
It could be something else, maybe some dependencies conflict, because :

#1 0x00007ffff43bb150 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2 0x00007ffff43bcc0f in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3 0x00007ffff43bcd81 in xcb_wait_for_reply64 () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4 0x00007ffff583b018 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff5836b1d in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ffff7862c4a in SDL_UpdateRect () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#7 0x00007ffff7862e66 in SDL_Flip () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
Is missing on my dbg result.

It's a real mess, I let you see if you can figure out what is going on.

[yoyz]

I will install my raspberry pi 2 which is easy.
And I will show you the result.
Maybe it's a quick fix, maybe not.

Thank you for doing all those test, now it's easier to understand. How I will reproduce the issue.

[lysergik]

Hello, since it's nearly a week and you didn't come up with anything yet, I guess you are either too busy and you didn't have any time to work this out or either the fix is quite complicated.
Anyway if you found out anything more precise or accurate than I've done so far, i would be glad to see your result. And then try to work this out on my side.

[yoyz]

I had no time at all.
I plugged my raspberry pi 2 with a hdmi cable and a rj45 cable.
Was not able to login...
So I need to reinstall It.
Will be faster than remember what I've tweak on my last project...

Yes, really busy those day...
But ping me on it, I will solve it... I don't think it's too hard to do.

What do you want to make with picoloop on raspberry pi 3 ? With what kind of synth, or drum machine ? Do you want midi on it ? The pi3, will be able to handle all synth engine IMHO.

[lysergik]

Ok that's fine.

If I want picoloop on a raspberry pi 3, it's to build my own groovebox, something that would get close to an Korg Electribe, Roland MC machine or even why not some Teenage Instrument OP-1 inspiration.
To build such a thing i looked a lot of raspbian compatible music software, and didn't find something as powerfull, lightweight and ergonomic as picoloop. Having the sequencer, different synth with some basic modulation parameter was exactly what I was looking for my groovebox software engine.

Then with a lite image of raspbian, I would install the picoloop dependencies and X11, and some script to have a coherent linux operating system for a groovebox.
To be more specific, I won't use midi out for this project, I will just stick to picoloop synth engine. As for midi in I have plan to wrote some .sh script with the program xdotool and also aseqdump, to make a proper midi to keystroke interface, and allow a midi controller to have a new way to use picoloop.
As for synth engine the rpi3 runs all the synth engine with the almost the same amount of ram than my laptop, and also doesn't crumble with it CPU, so it could handle a full build of picoloop if MDA Drum is fixed.

Then, for the hardware part, I would use the raspberry pi 3 as the computer unit, with an micro sd card as storage. Also an Adafruit kind of screen(maybe 3-5 inches), a Adafruit like battery and some tweaked laptop speaker. And the most important for rpi, an external soundcard, I think I will use my Behringer UCA222(or maybe I would get something cheaper).
As for the controller, first I will use my Axiom A.I.R mini 32 to test my mapping script, using rotative knob, pads, D-pad and keys. And when I would get an interesting mapping, I wish to make my own midi controller with an tennsy board, so I will include just the right number of control that I want to have an optimal picoloop/groovebox experience.
At the end I would create a simple box that contain the rpi3, it's screen, battery, sound card and the teensy controller, making it a real open source/ open hardware alternative to commercial groovebox.

If the final product of my hacking project reveal to have some real musical creation/representation assets, I consider release the image that I used with some free software/opensource licence, but also publish the instruction and plans to build a picoloop grovebox, with some tutorial to explain how to set up the a rpi like board with external soundcard, battery/screen and also how to make a the tennsy controller. And a plan to allow people to make the same box that I would have conceived. All this hardware setup would be kind of released in form of a free hardware licence.

So if one day this hacking project is done, it would give birth to an open source hardware groovebox project, mean't to run on raspberry pi or similar hardware. And the main goal of this project is to show that this sort of alternative can spare hundreds euros to musician, because a raspberry pi, a cheap external sound card and other small tech component, would cost according to my estimation, about 200€ max(more likely less). That would make a new kind of very cheap grooovebox beating even the price of the electribe 2, and all of this with an D.I.Y approach.
But also I hope if it it released that some kind of community to gather to maintain and improve the project, as all open source project, and at long term create a real alternative to commercial groovebox.

Sorry if that's was a bit long, but it's the most complex hacking project that I've ever had, and I've been thinking around it for month. And I have to say that discovering picoloop saved me a very very lot of time, because I don't have to assemble a tons of different music software together with jack, but just use picoloop. Now it's more the mapping part as well as the hardware part that I have to deal with(and still there are no very complex things to do.)

Anyway I hope you'll figure out who to fix MDA Drum.

[yoyz]

It's perfect :)
Years ago when I create picoloop I had a similar idea, really near this one, but more package.
I decide to make it available on console at the beginning, to make it portable in the beginning. The idea is to have the soft which work easily for everyone.

So if you are able to put this project to a goal, yes, I will be happy to see it !

Some hint.
Use rotary encoder they are cheap and it's reallllyyyyy simplier to program in the end from a GUI. Don't use analog pot, it's too difficult. Analog encoder could be good if they are able to work like infinite rotary pot. If they are like 99% of analog pot... It's not easy to use. Elektron box use infinite pot, and it's a better user experience.

You need button. Button help to talk to user interface.

Use only UART to communicate with the raspberry pi, UART is simple. I've think a lot about it, definitely, UART is the best hardware protocol for this kind of thing.

Don't use midi to talk to the software, it will be really too complicated. I've think it could be a good idea... But no, it's not a good idea at all. Midi is great to talk with synth, sequencer, but not good to talk to a user interface.

Use teensy 5v or arduino 5v. They are cheap and they have really enough CPU to handle every hardware needed : button and pot. And they have.... A lot of libs to talk to button, pots and stuff.

Use a 3d printer to make a good case.

In the end I highly recommend to work on the button, rotary, 3d printing case and a user protocol UART. This way I will be able to help you :) And believe me, it's not hard to do. It take a lot of time, but... No it's not complicated. Not at all !

I will fix the issue with mda drumsynth :)

[yoyz]

And last thing :)
I've the exact same goal in my mind.
Make an electribe 2/Elektron box open-source.
With the same level of integration.
The same performance.
So really close to a production device.
And it take times !
So no hurry :)

[lysergik]

I thought you had a similar vision of creating music, I felt it by using picoloop, it's maybe one of the most ergonomic linux music software.
I never heard of UART, but I will see how ot works. I will just use xdotool and my midi keyboard just to figure out a point to start with the controller and testing things around, and then go for a teensy controller. Anyway thanks for the tips.
I know it takes times, and there are no hurry to have, but I'm actually a college student, and so I'm in holiday right now. So I'm trying to use as much this free time to build it up. I will let know if it start to look like something useable.

[yoyz]

I've been able to reproduce the mda drumsynth issue.
I will work on a fix.

I will open myself a feature request on using multiple core to be able to have cursynth and twitch works without any sound frame drops on pi2.
On pi2, after 3 channel, I have drops, on pi3, there is enough power I think.
Today I spread a thread for the audio callback and one for the GUI.
But I need to use 4 thread for the audio synthesis on the raspberry pi 2 and 3.
It will help.

And last, thank you for your word !

[lysergik]

That's great, hope it won't be to hard to figure out what's going on.

I will try with my raspberry pi 3 to test cursynth/twitch up to 4 channel to see if it's buggy or not(even if I don't remember to notice something wrong with other synth).
And if you didn't came across that during your searches, it's known that the raspberry pi 1/2/3 soundcard is pretty cheap. And it tend to have some drops when the sound is process by alsa. Sometimes using jack could fix some sound issue(at least it work on my raspberry pi 1 on some application). Other ways used to fix that kind of problem, is to force the audio output, or send the sound by HDMI and last but not least use an external soundcard. But as you said, it's also possible that a 1,2GHz 4 core processor, is doing the job better than 900 GHz one.

[yoyz]

It's still on my TODO list.
This year is not the year for picoloop :)
But I know where the bug is hiding.

And yes, the 4 processor of the pi 2/3 can handle the load of picoloop.
One core of the pi 2, I know it begin to lag.
One core of the pi 3... Maybe it can work.
But when there is 4 core, you have to use 2 or 3 core at least. Today, I have serialized the synth processing.
A basic #pragma openmp will help.
It will be basically a little more than that, but yes, I will make the use of more core so no lag at all !

[lysergik]

Hello, since it's been nearly a month, is there any progress on the bug fixing ? However, if you don't have much time to fix this, could tell me which kind of raspberry pi x86 clone did you use to test picoloop on it ? So, I could build my picoloop based controller around that piece of hardware instead of the raspberry pi.
If you have also some idea for other x86 raspberry pi clone board, tell me. The thing that be nice is something with some specs that are near from a raspberry pi 3, And that have a easy way to be wired up with a small screen/battery power(so like the raspberry).
I've been experimenting some .sh script to translate midi signal into keyboard input. It's pretty basic, but it allowed me to make some lives longer than 1 hours of length. I will make some modification on that mapping to make more intuitive interaction between the user and the software through the use of a midi controller.
I think that then i will consider to get a Korg Nanokey Studio, because it seems to have a nice finition, design. And is not that expensive. Or if I'm very into it I will build my own(that would resemble a lot to one)

[lysergik]

Hi, it's been quite a long time since the last time. I just wanted to know if the bug had been fixed or if it's still in progress ? By the way I got recentley an electribe 2 and some korg volca's so my perspective on my project have changed, because I'm no longer in need of a fully functional groovebox as I did before and also got in touch with a real groovebox and understood how it actually work. Now I could satisfy my goal with only the raspberry pi 1 version of picoloop. I'm now more to tweak the raspberry(1 or higher version) to something closer to the volca concept. A small box, with a keyboard, few knob to play with synth parameter, a sequencer, LED's as way of display, and maybe some lcd screen, all that run by picoloop. So I just wanted to know if there's any mean to play a note on picoloop just with an input midi signal and then if a mode of pressing a rec button and then recording notes is a thing that could be implemented with no major difficulty or if it's just impossible so far. Also I've seen that some teensy code as been added no long ago, so what are the possibility in terms of linking picoloop controll to midi signal ?

Anyway I hope you'll fid some time to answer and i'm quite happy to notice that the project add some implementations those last months.

[yoyz]

Hi Lysergik,

As you can see I'm not so active on picoloop right now.
One thing which is planned which will be another binary on the same set of source code, is to use picoloop without the sequencer.
Basically, the whole idea, is to be able to create a set of track which will be "midi track" associated with a synth plugin.
If you look at the code of ./debian_wavesynth_rtaudio which is created by Makefile.debian_WaveSynth
You will see it's basically, a "one track" picoloop without sequencer to test thing easilly.
Right now it use the keyboard to play note, and it's really "raw" programming ( it's a test program ).
But moving it to a 4 track + midi, is definitely something I will be interested in the future.
Feel free to hack here, the code, is definitely not complicated and can be hacked easily, I can describe you things which could look complicated.

I have put the teensy code, for a simple reason.
It's code which is highly optimised by the community and which sound good.
So at one step, I will try to create some soft synth with it for really "low power" "low spec" SOC.
When ? That's the question :)

And yes, I have also a korg electribe 2, good stuff ! With volca attached, it's really good fun !

[lysergik]

Hi Yoyz,

I've been off Picollop for some time as well. Anyway I spend this time learning more consistently c++ and messing around with pure data and it helped me come back to picoloop with some more ideas and skills. Lately I've worked on a standalone c++ program that retreive alsa midi device messages in order to control a fake picoloop interface. At this point I am making the code less messy in order to add it to the rest of Picoloop. I also modified my own picoloop sources in order to upgrade picoloop's output, from a simple stereo channel to 4 mono channels, each one dedicated to a track. This way I succesfully outputed with jack each track individually to a pure data patch, wich handle mixing tools for each track and audio effects, so far I got really great result witch really outstand the simple delay embeded iinto picoloop code. The idea would then be to send some data to pure data within picoloop, either via some log file or loacl tcp/ip, to control the fx process patch while the patch is running in background. This way we could add easily any kind of audio treatment to each track, without reimplementing some c++ code, and since there's an important community around pure data it's easy to find some good fx.

I will maybe upload the code of a custom version of picoloop with a brandnew fx section when the code will be less hackish.

And thanks for telling me about the WaveSynth makefile, I will look at that !