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