• royal_orchestra

    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 )

    posted in technical issues read more
  • royal_orchestra

    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 ;-)

    posted in news read more
  • royal_orchestra

    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,...

    posted in news read more
  • royal_orchestra

    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):


    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.)

    posted in abstract~ read more
  • royal_orchestra

    By the way Tim Quitte just released a new version of his great sounding CAPS- ladspa plugins for realtime guitar use.
    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

    posted in extra~ read more
  • royal_orchestra

    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:
    Perhaps a path is different on our RPis?
    I think you should try to compile it on your RPi, then.

    posted in extra~ read more
  • royal_orchestra

    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 ):


    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 ;-)

    posted in extra~ read more
  • royal_orchestra

    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.



    posted in I/O hardware diyread more
  • royal_orchestra

    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
    (rtmidi is a C++-library)
    You need pyext installed in pd's startup-folder to use it within pd:
    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


    posted in extra~ read more
  • royal_orchestra

    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

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!