Purr Data is not for real-time MIDI and Audio projects!
Hello,
I know this issue title is a little bit provocative but it's the true reality I'm facing to. Am I the only one?
Thanks for releasing Purr Data v.2.10.1 (with Pd 0.48.0 & NW.js 0.24.4). For the record, Pd Vanilla is actually at v.0.50.2 and NW.js at v.0.44.5.
1- Despite the recent release of its last version, this open-source development software is not meeting yet its declaration of intention: "Purr Data serves the same purpose than Pd (Pure Data); i.e. a graphical data-flow programming environment which is geared towards real-time interactive computer music and multimedia applications but offers a new and much improved graphical user interface and includes many 3rd party plug-ins."
2- After few months of development, I arrived to the (temporary) conclusion that unfortunately I cannot use Purr Data for any serious real-time interactive computer music and audio projects. The real-time problems were increasing as my project was getting bigger even when the sub-patchs/GOPs are in idle mode.
These major issues seem to be linked to the combination of several elements, at least:
- Purr Data cannot handle simply several CPU in parallel when using only one patch contending several sub-patchs/GOPs.
- Purr Data modern GUI is too much CPU-consuming, due to at least the usage of only one CPU.
- Purr Data is not able to properly handle the Mouse, even when just moving it (with no click, no drag, no scroll).
- Purr Data is an old turtle when using Copy/Paste or Duplicate or Moving just few tens of objects in EditMode.
Please, have a look at some of my previous posts regarding these major issues:
- #581 - EditMode / Reliability Issues
- #555 - Thread 1 "purr-data" received signal SIGSEGV
- #553 - Copy/Paste / Duplicate / Move Weird behavior
And see also for MIDI objects:
- #563 - Support for 'Cyclone' 0.4
- #554 - Cyclone v.0.2 issues with MIDI
- #355 - 9 Cyclone objects that still need to be ported to Purr Data
3- After few weeks of heavy bugs testing of my MIDI/Audio project and Purr Data, it is now clear to me that this development tool has a lot of major and ongoing design issues which are not fixed yet, if they could be fixed.
I'm giving hereafter 3 new, significant and reproducible at will examples (under Linux). It's the same very bad behaviour under GNU/Linux (Linux Mint 19.3) with/without JACK as well as under Windows 10 (v.1909) with/without JACK or ASIO -and- DSP = OFF. No error or warning mentioned in the Console.
Purr Data 2.10.1 / All GOPs = IDLE (except [pd dt]) => Moving my Mouse => see the very unexpected impact on CPU load:
a- with EditMode = OFF (Purr Data + Task Manager together)
b- with EditMode = OFF (Purr Data + Htop alone)
c- with EditMode = ON (Purr Data + Task Manager together)
And then when I'm effectively running (with EditMode = Off) such or such GOP(s), the situation is getting worse and worse, leading very quickly to contentious erroneous MIDI values, audio glitches from short to long, random freezes of few seconds and finally totally freezing the whole project by just moving the mouse over the GOPs. This is an undocumented and hidden feature of Purr Data.
Note that I cannot test my project under Pd Vanilla as it is loading it but with too many errors, just displaying about half of the GOPs and these GOPs are not functional even for stand-alone ones, with the required externals well loaded.
4- An example of Warnings messages in the Console after having closed my 'MDR-E+' project (with just Open / No use of the GOPs / Close)
[4] image: warning: no image data in cache to free legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .93778a40 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9377a630 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9377c220 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9377de10 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9377e130 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9377e450 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9377e770 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9377ea90 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9377edb0 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .93798e00 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9379a9f0 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9379c5e0 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9379e1d0 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9379fdc0 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .937a19b0 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .937a35a0 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .93805260 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9381b9c0 0 legacy tcl command at 201 of ../shared/hammer/file.c: hammereditor_close .9383c470 0 error: x55839318a5d0: no such object
5- Reading again the useful "Meet the Cat: A Quick Introduction to Purr Data" written by Albert Gräf didn't help me. So, for the time being, I put with regret my 'MDR-E+' project developed with Purr Data in standby (confinement!) until this situation could be clarified... or not.
Don't get me wrong. Purr Data is a great piece of open-source software and many thanks to the team working on it. It's viable as long as you are using it only for small projects like 'Simple MIDI Sequencer', my 2nd project under Purr Data. But as soon as you start to use it for bigger projects (but still reasonable), like my 'Music Disk Record Emulator+' (an emulation of a 30 years old Yamaha MIDI hardware) its MIDI and Audio real-time limitations become more than obvious.
And for me, Pure Data Vanilla is not a viable alternative due to its bad looking and obsolete GUI.
Best,