I’m also working on a looper pedal using a RPI3. It is based on Katja’s suggestion to use poke~ for writing driven by counter~.
Erasing a bigger array always crackles on my pi even with volume down. [*~ 0] I guess because there is a cpu spike.
I use another poke~ to zero the array, just increase the index value so it is a bit earlier than tabread~.
I don’t resize arrays, I just manipulate the min and max points of the counter~ object.
Right now there are 9 arrays, 120seconds long, running parallel without any problems.
( note : replaced [ wrap~] with [expr~ $v1%$v2] , somehow wrap~ produced incorrect, non integer index values )

less than a second. In the context of typing a name that is unfortunately too much latency to be usable.

Typing the name of a library, a folder or the first few letters of an object, hitting tab- or arrow-key,
wait <1 second and get an popup-menu with suggestions to choose from - would be ok for me.

I'm looking forward for your solution

I think it is more important to have good autocompletion first. cmd+1, a few letters then tab is nearly equal to a shortcut for me. I liked the autocompletion plugin for pd-extended because it was possible to make it search for objects in libraries - show all objects in a library or reverse: which libraries have this object ? I also added my own abstractions and their subfolders. This keeps me from making the same abstractions several times, and find old stuff again.
-> A file-browsing autocompletion would be nice, I don't know if this slows it down.

Anyway I agree that it would be nice to have the possibility to change or create shortcuts at least for menu items, zoom,... -very useful for users with different keyboard layouts, like german, french,...

Hi,
I did lights and music for a theatre-performance last week. Stage lighting and sample playback should be tightly syncronised so I made a rather simple lighting desk in pd. (using an Enttec DMX USB Pro) The core of a lighting desk is the ability to fade the brightness of several (hundreds of) lamps over given times. I could not find a line object for lists of integers within a short research so I decided to make one. I used dynamic patching because I didn't want to connect up to 512 objects by myself.
Here is what I ended up with (helpfile included):

list-line-i.zip

It worked reliable in the rehearsals and shows, but I'd like to get some opinions: Is this the way to solve this kind of tasks?
It feels like a hack somehow. The dynamically created subpatch is hard to maintain. For example once I realized it needs behavior like max's | pak | or every line-object should only output integers I got a sudden headache...
I'd just like to know if this kind of programming is the way to go in puredata or are there some smarter techniques I don't know?

best regards

(by the way if someone likes to get the whole DMX-lighting patch let me know.)

By the way Tim Quitte just released a new version of his great sounding CAPS- ladspa plugins for realtime guitar use.
http://quitte.de/dsp/caps.html
Most of these plugins work very well with ladspa~ on RPI. (Some are too demanding without sse-hardware). Now there is also a light-weight cabinet simulation.
Best regards

Sorry, I don't know...
pd can't use the external above on other hardware than RPi.
If your on RPi, it should work, when you put it in the startup- folder. | import py | tends to crash pd.
General Documentation and example patches / scripts for pyext can be found here:
http://grrrr.org/research/software/py/
Perhaps a path is different on our RPis?
I think you should try to compile it on your RPi, then.

Hi,
I just found out the DSP of Guitarix is done in Faust. So I compiled all *.dsp Files in the source-code as pd-externals using Faust.
I had to fix some dependencies - I just put everything g++ can't find in the "faust"-folder, and did some minor changes to the source code (valve.h and 12ax7.cc):

That's it!
Every external I tried works. Nearly 200 externals, including amp-simulations, tonestacks, stompbox-fx, a lot of building blocks, ...
I could not figure out how the cabinet-simulation works, though - something with IR I guess. Maybe some objects only make sense inside Guitarix. Some are too demanding for this small cpu.
Here is the library I compiled for Raspberry Pi. ( from the LV2 source code ):

guitarix_2_pd_armhf.zip

example helpfile included.
Have fun to try these things and please let me know if you have some hints on how to put the building-blocks in a meaningful order

Yeah!
How did you build the actuator that moves the strings? Electromagnetic coils ? and how do you drive them?
This would be great on a Zither also.

lg
Jens

Hi,
I had some problems with midi on raspberry pi and made an external with pyext to get midi in and out on an alternative way for troubleshooting. I did this to learn some more python, also.
To my surprise some irregular audio i/o warnings and clicks i had before did not show up using this externals anymore.( closed any midi connections in the pd-midi dialogue.)
I got curious and measured hardware midi roundtrip latency using the timer-object. Compared with pd's alsa-midi and oss-midi it is much faster.
I read somewhere pd's midi is somehow synced to the audiobuffersize, perhaps this is the reason midi is faster via python(?)
The script relies on the python-rtmidi library
https://pypi.python.org/pypi/python-rtmidi
(rtmidi is a C++-library)
You need pyext installed in pd's startup-folder to use it within pd:
http://grrrr.org/research/software/py/
I attached the script (needs to be in the pd-path) and a pd patch to demonstrate and test it.
On my Raspberry Pi i measured usually 2.3ms lateny using rtmidi (min. 1.3, max 4ms) and ~5.3ms using pd's alsa-midi and the built-in objects (min 4, max 6.6), running headless with no gui, audiobuffersize 6.

Tested with Raspbian wheezy, pd-extended 0.43.4, python 2.7.3, pyext 0.2.2
I'm learning python, suggestions welcome
Jens

http://www.pdpatchrepo.info/hurleur/rtpyio.zip

Hi,
I don't understand this behaviour:
When I send a sysex message to midiout, midiin (and sysexin) receive it.

• also when nothing is connected to the midi-interface
  Also when I send something to noteout it comes back from midiin and notein.
  Can I remove the midi-feedback-loop in my alsa configuration?

I had a cheap noname usb-midi interface (oss-driver), which did not do that.
This interface was not reliable for sysex-messages so I replaced it by a m-audio midisport uno. It works great, it receives and transmits long sysex-messages without errors.( alsa-midi driver)
But in pd the outgoing messages get to the midin also.
I tried sending a string with amidi instead (ping to my synth):
amidi --port=hw:2,0,0 --send-hex="f0 00 00 7e 4b 00 0f f7" --dump

amidi shows no repeating output on the input (only pong from synth), so it must be something related to pd (or alsa-midi routing?).

raspbian wheezy, pd-extended

Can I change this somehow? Is there an oss-driver for midisport uno?

Cleaning up the received data is stupid work and I hope unnecessary...
best regards

Hi,
i have built a puredata-stompbox. The main part is a raspberry pi running raspbian wheezy and pd-extended. Everything works fine now, but new externals don't work. I tried munger~ and +bubbler~. I put *.pd_linux binaries i found on the web in the searchpath, pd finds them but complains "cannot open shared object: no such file or directory". -Why? Do I need externals compiled for the raspberry pi?
best regards

Here is the pyext build i made on my raspberry pi. If you don't want to compile pyext for raspberry by yourself, you could try it first.

http://www.pdpatchrepo.info/hurleur/py.pd_linux

sorry- I didn't want to bother you with patches you don't need.
Just thought it might be interesting for other forum-readers.
Thanks for the patch, I didn't know a lot of objects.
Midirealtimein works good. I didn't know that midiin doesn't output Midi-clock.

I just created some random Timecode - Messages following the rules described on Wikipedia and could successfully send and receive full-time-codes and complete quarter frame messages with built-in pd-objects on linux.

Perhaps it is a windows-driver problem?
Jens

Thanks for your clarifications. learned something.
I was not aware how Midi Timecode works and will try midirealtimein.
The default buffersize of rtmidi is 1024 Bytes for example. But receiving nothing instead is suspicious...
My cheap Midi-to-USB-cable only receives the first 3 bytes of sysex-messages. I think it expects notes, but you are right - perhaps the software is often the bottleneck.

Just for fun I tried to get rtmidi working with pyext again and understand this language much better now. I attached the script for pyext and a pd-testpatch. The external spits out sysex, notes, controller, midiclock as lists or stream of numbers. If my first Python script works on your machine, this external should also receive sysex within pd.
You should close pd's midi-inputs (with alsa-midi driver on linux you can leave it open).
I just tried this external on my raspberry pi and saw nearly no audio i/o error warnings anymore- a nice side-effect! Perhaps pyext scripts have lower priority?
Buffersize for sysex is 4096 Bytes.

tested on raspberry pi with pd-extended 0.43.4, py/pyext, python 2.7, python-rtmidi

jens

http://www.pdpatchrepo.info/hurleur/rtpy.zip

Did you lower USB-speed, yet?
In /boot/cmdline.txt :
dwc_otg.speed=1

http://wiki.linuxaudio.org/wiki/raspberrypi

If your soundcard can't work with USB1.1, you can't use it. Raspberry Pi doesn't work well with USB2.0 Soundcards.
There is an USB-Audio-Fix you could try. (But it doesn't work for me)

http://www.raspyfi.com/raspberry-pi-usb-audio-fix/

(the instructions on this site are old, the fix is included in the "next"-branch, not "fiq_split"-branch:)

sudo apt-get install git-core
sudo wget http://goo.gl/1BOfJ -O /usr/bin/rpi-update && sudo chmod +x /usr/bin/rpi-update
sudo BRANCH=next rpi-update

best regards

I tried a bit on linux and mac and saw that midiclock input is not working with pd-extended. Perhaps it works in newer pd vanilla versions:

http://lists.puredata.info/pipermail/pd-dev/2013-08/019599.html

> > On Fri, Jul 05, 2013 at 04:36:46PM -0700, Miller Puckette wrote:
> >> Hmm... just looking at the code in s_midi_pm.c I can't understand how
> >> it could ever have worked for sysex or 'system' messages.

Perhaps midi-input works better in pd-extended 0.44?
I couldn't compile the latest pd-extended 0.44 on linux, so I tried a workaround with a python script that forwards midiinput to an udp-port. This works to get midiclock and sysex into pd-extended.

You need python and python_rtmidi:
https://pypi.python.org/pypi/python-rtmidi

Python-script and Pd-patch attached.
start the python-script from terminal and don't use oss-midi in pd (alsa or no midiinput at all), because this will block alsa-midi from opening the midiport.

Tried on Raspberry pi, pd-extended 0.43, python 2.7

Does someone know if this is also possible with py/pyext?
I could print midi-messages to the pd-window but I don't understand object oriented programming enough to get the midi-messages out of an pyext outlet.)

best regards
Jens

http://www.pdpatchrepo.info/hurleur/midiclock_py2pd.zip

I found the problem.
There is a alsa midi-through device that has to be disabled:

"
sudo rmmod snd_seq_dummy

permanently:

sudo sh -c "echo blacklist snd_seq_dummy > /etc/modprobe.d/blacklist-seq-dummy.conf"

which will create a configuration file that tells modprobe (the linux device driver loader) not to load snd_seq_dummy. It can be easily reversed by just deleting the file.)
"

pd connects automatically to it i think.

"aconnect -i -o -l"

shows all virtual midi connections.

Ok, this works fine, but now I have to discover why Pd does not start alsa-midi with my startup script in etc/rc.local .... grrrrrr.

@ shawnb

I'm using Pd 0.43.4-extended on a Raspberry Pi running Linux (Raspbian).
On Mac sysex stuff works, but I can't try on windows.
Can't you try midiin instead of sysexin?

A lot of midi hardware does not work good with sysex messages:

http://www.midibox.org/dokuwiki/doku.php?id=midi_interface_blacklist

I don't get why it is so complicated to send a few bytes..

But if it is really pd win that does not work with sysex, perhaps you could get it into pd via a python script that sends it via udp or pyext to Pd. I think I saw a midi library for python somewhere.

best regards
Jens

Hi,
i made some Pots talk to Pd by connecting a mcp3208 to the gpio. Polling and Reading is done by a Python script based on this german document:
http://erik-bartmann.de//download/PiMeUp_MCP3008.pdf
The Python script is loaded on startup and communicates to Pd via Udp.
Connecting to Python this way is great since I can can also send messages from Pd to a lcd and the system even when I am not logged in as root.
It is not so hard to do but you will need an A/D-Converter like the mcp3208 for the pots.
best regards

here is the soundfile:

I did some tests now. Pd crashes sometimes when I try to change creation arguments of munger~. If I don't use any it works great.
I'll try to attach a mp3 with an example of a guitarchord in the frozen internal buffer, changing some settings with the pots of the stompbox. The patch has an additional delayline syncronized to the grain separation.
Jens