(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
cheers Miller
On Tue, Jul 13, 2021 at 10:22:17AM -0700, Miller Puckette via Pd-dev wrote:
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
All good things, thanks Miller. While we're dreaming: tooltip style message inspection - when active, hover over a wire to see what's flowing or audition audio (maybe through compressor/limiter :) best, Andy
cheers Miller
YEah, while I'm meessing with hovering I want ot do something like that (but probably just graphical - I don't want to blow anyone out of his/her seat by accident :)
On Tue, Jul 13, 2021 at 07:11:04PM +0100, Andy Farnell wrote:
On Tue, Jul 13, 2021 at 10:22:17AM -0700, Miller Puckette via Pd-dev wrote:
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
All good things, thanks Miller. While we're dreaming: tooltip style message inspection - when active, hover over a wire to see what's flowing or audition audio (maybe through compressor/limiter :) best, Andy
cheers Miller
On the topic of minor message related improvements, I hope it's ok to chime in here, and I apologize if this has been hashed to death already and there are good reasons for the current state..
I'm doing a lot of making messages out of other objects to send to Scheme for Pd, and one thing I use all the time in Max is the right hand inlet for message boxes as a way to set the contents of a message. I'm curious whether there has been thought about adding that to Pd message boxes. It's a small thing, but very handy for the kind of patches I wind up making.
thanks! iain
On Tue, Jul 13, 2021 at 11:15 AM Miller Puckette via Pd-dev < pd-dev@lists.iem.at> wrote:
YEah, while I'm meessing with hovering I want ot do something like that (but probably just graphical - I don't want to blow anyone out of his/her seat by accident :)
On Tue, Jul 13, 2021 at 07:11:04PM +0100, Andy Farnell wrote:
On Tue, Jul 13, 2021 at 10:22:17AM -0700, Miller Puckette via Pd-dev
wrote:
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or
lists
All good things, thanks Miller. While we're dreaming: tooltip style message inspection - when active, hover over a wire to see what's flowing or audition audio (maybe through compressor/limiter :) best, Andy
cheers Miller
--
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Hi, I have this PR with documentation updates and I see already we got conflicts with the new commits from yesterday and I don't really know how to resolve them https://github.com/pure-data/pure-data/pull/1259
See what you can merge and then we can close and I can start a new PR
cheers
Em ter., 13 de jul. de 2021 às 14:23, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
also very helpful in max, connected to tooltips:
- when double clicking in a send/receive object, a list of the objects connected to it appears, and clicking on it opens up the canvas where they are. the same should be done also for receive~/send~ + throw~/catch~. Ideally solving automatically when $1-variables are used in the symbols.
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/list
Hi Miller,
great to see Pd 0.52 approaching!
Here's a list of my open PRs: https://github.com/pulls?q=is%3Aopen+is%3Apr+author%3ASpacechild1+archived%3...
I made sure that they all apply cleanly.
---
Some are trivial:
* https://github.com/pure-data/pure-data/pull/769
* https://github.com/pure-data/pure-data/pull/764
---
Others need more discussion:
* https://github.com/pure-data/pure-data/pull/630
* https://github.com/pure-data/pure-data/pull/849
---
Here are some simple feature PRs:
* [goprect( method to dynamically change the GOP rect: https://github.com/pure-data/pure-data/pull/627
* allow to receive large UDP packets: https://github.com/pure-data/pure-data/pull/1122
* [clone]: allow resizing and always have at least one inlet: https://github.com/pure-data/pure-data/pull/1069
* "-open-with-args" command line option: https://github.com/pure-data/pure-data/pull/1064
---
These are bit larger, but still reasonable (at least I like to think so :-)
* new [list store] methods: [set(, [insert(, [delete(, [send(: https://github.com/pure-data/pure-data/pull/594
* [poly]: allow resizing, dynamically set note stealing, sustain pedal mode: https://github.com/pure-data/pure-data/pull/661
* new [list] methods: [list foreach], [list join] and [list unjoin]: https://github.com/pure-data/pure-data/pull/595
---
Finally, this one would make me very happy: https://github.com/pure-data/pure-data/pull/1117
I would definitely see this as a temporary solution. After Gem and ophelia (who else?) have adapted their macOS input handling code, the option could be removed entirely.
Cheers,
Christof
On 13.07.2021 19:22, Miller Puckette via Pd-dev wrote:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
my suggested PR made by me:
- add dejavu sns mono italic and bold italic this was promised for the last version, but it was just too late https://github.com/pure-data/pure-data/pull/899
Some relatively simple PRs: - pdcontrol updates https://github.com/pure-data/pure-data/pull/828 - Add a 'depth' argument to [namecanvas] https://github.com/pure-data/pure-data/pull/837 - allow [symbol] to convert float and lists https://github.com/pure-data/pure-data/pull/987 - Add initbang / closebang objects https://github.com/pure-data/pure-data/pull/616 - add arguments and flags to bob~ https://github.com/pure-data/pure-data/pull/1006
I was also hoping we could make several changes, improvements and fixes to GUIs, I have organized bugs and features here: https://github.com/pure-data/pure-data/issues/947
One that I'm most excited about is adding a vanilla [knob] object and we worked a lot on this one, seems great and ready to go https://github.com/pure-data/pure-data/pull/938
cheers
Em ter., 13 de jul. de 2021 às 14:23, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Em qua., 14 de jul. de 2021 às 00:03, Alexandre Torres Porres < porres@gmail.com> escreveu:
my suggested PR made by me:
- add dejavu sns mono italic and bold italic this was promised for the
last version, but it was just too late https://github.com/pure-data/pure-data/pull/899
Some relatively simple PRs:
- pdcontrol updates https://github.com/pure-data/pure-data/pull/828
These are some additions to [pdcontrol] and the first one that may need some more serious dabate maybe.
By the way, other things I could point.
This fixes a bug in delwrite~ that I've been hoping to be fixed since Pd 0.46 :) => https://github.com/pure-data/pure-data/pull/708
And I needed this for an external of mine => https://github.com/pure-data/pure-data/pull/1324
thanks
Hello,
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
That is really exciting news, since I do most physical project on ESP32xxx for distributed computermusic projects from speaker to robotic instruments.
So please let us know how it progress if you need for testing debug or other helps. Maybe can help with objects helping interfacing the Peripheral possibilities, from touch to solenoids drive...
Are you targeting the ESP-IDF/ESP-ADF framework ?
mfg winfried
Cool, that's excellent news. I'm using the ADF i2s audio driver but staying away from their "streams" since they're too clunky (and they eat memory). I have only audio, bluetooth serial emulation, and SD card filesystem, no threaded readsf or networking (probably too memory-intensive again).
I had to go way out on a Pd branch to get it running, but I want to rebase all that once I get the Pd source in better shape to support it.
cheers Miller
On Wed, Jul 14, 2021 at 10:32:23AM +0200, Winfried Ritsch wrote:
Hello,
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
That is really exciting news, since I do most physical project on ESP32xxx for distributed computermusic projects from speaker to robotic instruments.
So please let us know how it progress if you need for testing debug or other helps. Maybe can help with objects helping interfacing the Peripheral possibilities, from touch to solenoids drive...
Are you targeting the ESP-IDF/ESP-ADF framework ?
mfg winfried
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - https://urldefense.proofpoint.com/v2/url?u=http-3A__iem.at_ritsch&d=DwIC...
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Am Mittwoch, 14. Juli 2021, 18:03:32 CEST schrieb Miller Puckette via Pd-dev:
Cool, that's excellent news. I'm using the ADF i2s audio driver but staying away from their "streams" since they're too clunky (and they eat memory). I have only audio, bluetooth serial emulation, and SD card filesystem, no threaded readsf or networking (probably too memory-intensive again).
Starting with the DIYasb [1], distributed streaming devices for field recording and audio projections using Pd, want to include the AOO-Streaming [2] functionality, already tested and used also for VRR [3] now for ESP32xx devices, especially simple Ambisonics Mics and field-speaker for a future project.
Doing simple streaming over WiFi, I did not get any trouble using opus lib, but did no extensive processing until now and allowed enough latency for these applications, but have to dig in deeper... not using bluetooth and waiting for the ESP32S3...
I had to go way out on a Pd branch to get it running, but I want to rebase all that once I get the Pd source in better shape to support it.
thats fine, please keep us updated.
mfG Winfried
References
[1] https://git.iem.at/cm/diyasb [2] https://git.iem.at/cm/aoo [3] https://vrr.iem.at/ [4] https://git.iem.at/uC/
cheers Miller
On Wed, Jul 14, 2021 at 10:32:23AM +0200, Winfried Ritsch wrote:
Hello,
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
That is really exciting news, since I do most physical project on ESP32xxx for distributed computermusic projects from speaker to robotic instruments.
So please let us know how it progress if you need for testing debug or other helps. Maybe can help with objects helping interfacing the Peripheral possibilities, from touch to solenoids drive...
Are you targeting the ESP-IDF/ESP-ADF framework ?
mfg winfried
Yeah, AOO on RTOS will be cool! For that we should drop bluetooth in favor of some flavor of WIFI I think.
It's tricky getting everything to fit in 512K RAM - I think the new ESP32S3 has the same memory size, so that will be the limiting aspect.
cheers M
On Thu, Jul 15, 2021 at 12:09:45PM +0200, Winfried Ritsch wrote:
Am Mittwoch, 14. Juli 2021, 18:03:32 CEST schrieb Miller Puckette via Pd-dev:
Cool, that's excellent news. I'm using the ADF i2s audio driver but staying away from their "streams" since they're too clunky (and they eat memory). I have only audio, bluetooth serial emulation, and SD card filesystem, no threaded readsf or networking (probably too memory-intensive again).
Starting with the DIYasb [1], distributed streaming devices for field recording and audio projections using Pd, want to include the AOO-Streaming [2] functionality, already tested and used also for VRR [3] now for ESP32xx devices, especially simple Ambisonics Mics and field-speaker for a future project.
Doing simple streaming over WiFi, I did not get any trouble using opus lib, but did no extensive processing until now and allowed enough latency for these applications, but have to dig in deeper... not using bluetooth and waiting for the ESP32S3...
I had to go way out on a Pd branch to get it running, but I want to rebase all that once I get the Pd source in better shape to support it.
thats fine, please keep us updated.
mfG Winfried
References
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__git.iem.at_cm_diyasb&am... [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__git.iem.at_cm_aoo&d... [3] https://urldefense.proofpoint.com/v2/url?u=https-3A__vrr.iem.at_&d=DwICA... [4] https://urldefense.proofpoint.com/v2/url?u=https-3A__git.iem.at_uC_&d=Dw...
cheers Miller
On Wed, Jul 14, 2021 at 10:32:23AM +0200, Winfried Ritsch wrote:
Hello,
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
That is really exciting news, since I do most physical project on ESP32xxx for distributed computermusic projects from speaker to robotic instruments.
So please let us know how it progress if you need for testing debug or other helps. Maybe can help with objects helping interfacing the Peripheral possibilities, from touch to solenoids drive...
Are you targeting the ESP-IDF/ESP-ADF framework ?
mfg winfried
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - https://urldefense.proofpoint.com/v2/url?u=http-3A__iem.at_ritsch&d=DwIC...
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
It's tricky getting everything to fit in 512K RAM - I think the new ESP32S3 has the same memory size, so that will be the limiting aspect.
On the ESP32-S2 it's possible to use up to 4MB of external RAM: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s2/api-guides/ext...
Still not a lot, but better than 512KB :-)
Christof
On 15.07.2021 21:39, Miller Puckette via Pd-dev wrote:
Yeah, AOO on RTOS will be cool! For that we should drop bluetooth in favor of some flavor of WIFI I think.
It's tricky getting everything to fit in 512K RAM - I think the new ESP32S3 has the same memory size, so that will be the limiting aspect.
cheers M
On Thu, Jul 15, 2021 at 12:09:45PM +0200, Winfried Ritsch wrote:
Am Mittwoch, 14. Juli 2021, 18:03:32 CEST schrieb Miller Puckette via Pd-dev:
Cool, that's excellent news. I'm using the ADF i2s audio driver but staying away from their "streams" since they're too clunky (and they eat memory). I have only audio, bluetooth serial emulation, and SD card filesystem, no threaded readsf or networking (probably too memory-intensive again).
Starting with the DIYasb [1], distributed streaming devices for field recording and audio projections using Pd, want to include the AOO-Streaming [2] functionality, already tested and used also for VRR [3] now for ESP32xx devices, especially simple Ambisonics Mics and field-speaker for a future project.
Doing simple streaming over WiFi, I did not get any trouble using opus lib, but did no extensive processing until now and allowed enough latency for these applications, but have to dig in deeper... not using bluetooth and waiting for the ESP32S3...
I had to go way out on a Pd branch to get it running, but I want to rebase all that once I get the Pd source in better shape to support it.
thats fine, please keep us updated.
mfG Winfried
References
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__git.iem.at_cm_diyasb&am... [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__git.iem.at_cm_aoo&d... [3] https://urldefense.proofpoint.com/v2/url?u=https-3A__vrr.iem.at_&d=DwICA... [4] https://urldefense.proofpoint.com/v2/url?u=https-3A__git.iem.at_uC_&d=Dw...
cheers Miller
On Wed, Jul 14, 2021 at 10:32:23AM +0200, Winfried Ritsch wrote:
Hello,
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
That is really exciting news, since I do most physical project on ESP32xxx for distributed computermusic projects from speaker to robotic instruments.
So please let us know how it progress if you need for testing debug or other helps. Maybe can help with objects helping interfacing the Peripheral possibilities, from touch to solenoids drive...
Are you targeting the ESP-IDF/ESP-ADF framework ?
mfg winfried
--
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch@iem.at - https://urldefense.proofpoint.com/v2/url?u=http-3A__iem.at_ritsch&d=DwIC...
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
Am Donnerstag, 15. Juli 2021, 21:39:32 CEST schrieben Sie:
Yeah, AOO on RTOS will be cool! For that we should drop bluetooth in favor of some flavor of WIFI I think.
It's tricky getting everything to fit in 512K RAM - I think the new ESP32S3 has the same memory size, so that will be the limiting aspect.
Thats true, still a microprocessor, ESP32 is still the biggest with 520kB SRAM, but PSRAM 2-8G is also quite fast on the S3, but I think dual core of S3 would be better than on ESP32-S2, which I use for robotics instruments. ESP32 for Audio (mostly from Olimex [1]).
mfg winfried
[1] https://iaem.at/kurse/ws2021/phycm/olimex-player
cheers M
On Thu, Jul 15, 2021 at 12:09:45PM +0200, Winfried Ritsch wrote:
Am Mittwoch, 14. Juli 2021, 18:03:32 CEST schrieb Miller Puckette via Pd-
dev:
Cool, that's excellent news. I'm using the ADF i2s audio driver but staying away from their "streams" since they're too clunky (and they eat memory). I have only audio, bluetooth serial emulation, and SD card filesystem, no threaded readsf or networking (probably too memory-intensive again).>
Starting with the DIYasb [1], distributed streaming devices for field recording and audio projections using Pd, want to include the AOO-Streaming [2] functionality, already tested and used also for VRR [3] now for ESP32xx devices, especially simple Ambisonics Mics and field-speaker for a future project.
Doing simple streaming over WiFi, I did not get any trouble using opus lib, but did no extensive processing until now and allowed enough latency for these applications, but have to dig in deeper... not using bluetooth and waiting for the ESP32S3...
I had to go way out on a Pd branch to get it running, but I want to rebase all that once I get the Pd source in better shape to support it.
thats fine, please keep us updated.
mfG Winfried
References
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__git.iem.at_cm_diyasb &d=DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=1G1ft6Y7XaTq dv7GIbZgQevQVIh7dCEYyqblVJUOl8A&s=REqsW94KN3j1zmoTc8fuAzacKH95auw8rnFkm2yK quQ&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__git.iem.at_cm_aoo&d... DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=1G1ft6Y7XaTqdv7 GIbZgQevQVIh7dCEYyqblVJUOl8A&s=2H_p8O28epbFdWYd9CdZKxGVaqQIKSEQwpA0UiSQg4c &e= [3] https://urldefense.proofpoint.com/v2/url?u=https-3A__vrr.iem.at_&d=DwICA... &c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=1G1ft6Y7XaTqdv7GIbZgQ evQVIh7dCEYyqblVJUOl8A&s=uN5zUyzjx7xUPEbzK821HONeuQM_qgtNQWdVdA1c6lQ&e= [4] https://urldefense.proofpoint.com/v2/url?u=https-3A__git.iem.at_uC_&d=Dw... CAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=1G1ft6Y7XaTqdv7GIb ZgQevQVIh7dCEYyqblVJUOl8A&s=1r_RHEIuU6WoOrdkiSLsH21Z2Ybjm-
GBtKKuX1P5Y2M&e=>
cheers Miller
On Wed, Jul 14, 2021 at 10:32:23AM +0200, Winfried Ritsch wrote:
Hello,
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
That is really exciting news, since I do most physical project on ESP32xxx for distributed computermusic projects from speaker to robotic instruments.
So please let us know how it progress if you need for testing debug or other helps. Maybe can help with objects helping interfacing the Peripheral possibilities, from touch to solenoids drive...
Are you targeting the ESP-IDF/ESP-ADF framework ?
mfg winfried
On 14/7/21 1:22 am, Miller Puckette via Pd-dev wrote:
(so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs)
Sounds amazing. What I wouldn't give for one of those boards with multiple audio inputs. Pd powered pocket mixer.
Chris.
Yeah, or 6-channel processor you can mount on a guitar :)
M
On Wed, Jul 14, 2021 at 08:24:33PM +0800, Chris McCormick wrote:
On 14/7/21 1:22 am, Miller Puckette via Pd-dev wrote:
(so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs)
Sounds amazing. What I wouldn't give for one of those boards with multiple audio inputs. Pd powered pocket mixer.
Chris.
-- https://urldefense.proofpoint.com/v2/url?u=https-3A__mccormick.cx_&d=DwI...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
what are the dimension of this? could't find it
Em qua., 14 de jul. de 2021 às 13:13, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
Yeah, or 6-channel processor you can mount on a guitar :)
M
On Wed, Jul 14, 2021 at 08:24:33PM +0800, Chris McCormick wrote:
On 14/7/21 1:22 am, Miller Puckette via Pd-dev wrote:
(so I can run it on an Espressif LyraT board, which I think takes only
about
10 or 20% of the current that a Pi needs)
Sounds amazing. What I wouldn't give for one of those boards with
multiple
audio inputs. Pd powered pocket mixer.
Chris.
--
https://urldefense.proofpoint.com/v2/url?u=https-3A__mccormick.cx_&d=DwI...
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
--
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Hi Miller,
I'm very enthusiastic about the FreeRTOS port, this would open so many possibilities. I think FreeRTOS will run on the RPi too and possibly also on the Teensy. For the tooltips, I would hope that the GUI vs. audio engine separation for libpd would be finalized so that alternative GUI frameworks can be contributed. Thinking of the endless discussions of fontsize and cross-platform rendering issues in Tk, maybe that effort is better invested in taking inspiration from PurrDatas SVG rendering. I think Pd would benefit from the ability to write custom GUIs ans ship them like abstractions. That would close the gap to webaudio too, which works already today via libpd and emscripten - just imagine the possibilities of a native browser friendly GUI on top of it.
M.
On 13.07.21 19:22, Miller Puckette via Pd-dev wrote:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I would hope that the GUI vs. audio engine separation for libpd would be finalized
I think the GUI vs audio seperation has not even started yet :-)
However, I would agree that this is a very important long term goal, for all the reasons you've listed.
Christof
On 15.07.2021 11:57, Max wrote:
Hi Miller,
I'm very enthusiastic about the FreeRTOS port, this would open so many possibilities. I think FreeRTOS will run on the RPi too and possibly also on the Teensy. For the tooltips, I would hope that the GUI vs. audio engine separation for libpd would be finalized so that alternative GUI frameworks can be contributed. Thinking of the endless discussions of fontsize and cross-platform rendering issues in Tk, maybe that effort is better invested in taking inspiration from PurrDatas SVG rendering. I think Pd would benefit from the ability to write custom GUIs ans ship them like abstractions. That would close the gap to webaudio too, which works already today via libpd and emscripten - just imagine the possibilities of a native browser friendly GUI on top of it.
M.
On 13.07.21 19:22, Miller Puckette via Pd-dev wrote:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I have had this PR open for a while: https://github.com/pure-data/pure-data/pull/1261 . It adds threaded behaviour for disk and network I/O, making the Pd audio thread "real-time safer". I went through quite a few revisions courtesy of umlaeute and Spacechild1, but haven't heard from you directly. I am happy to do some more work if there is interest in merging. CI build currently fails because of weird "support" of ssize_t on VS (happy to hear about workarounds). Best, Giulio
Miller Puckette via Pd-dev wrote on 13/07/2021 19:22:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Dear Giulio,
Am I right to assume that this would include writing arrays to disk without interfering with the audio thread?
Best! Edwin
On 16 Jul 2021, at 00:18, Giulio Moro via Pd-dev pd-dev@lists.iem.at wrote:
I have had this PR open for a while: https://github.com/pure-data/pure-data/pull/1261 . It adds threaded behaviour for disk and network I/O, making the Pd audio thread "real-time safer". I went through quite a few revisions courtesy of umlaeute and Spacechild1, but haven't heard from you directly. I am happy to do some more work if there is interest in merging. CI build currently fails because of weird "support" of ssize_t on VS (happy to hear about workarounds). Best, Giulio
Miller Puckette via Pd-dev wrote on 13/07/2021 19:22:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...) To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/). Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another. This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what? PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists cheers Miller _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Am I right to assume that this would include writing arrays to disk without interfering with the audio thread?
I don't think so, but there's already a separate PR for that: https://github.com/pure-data/pure-data/pull/1357
Actually, I am not sure what Giulio meant with "disk I/O". Maybe that the I/O thread could also be used to stream audio to/from disk? Personally, I would keep networking and audio streaming on different threads as they don't necessarily have the same priority.
---
Generally, I see three categories of worker threads:
1) the task has to meet a certain deadline. One example is streaming audio to/from disk: it eventually has to happen within a certain time frame, but the time frame can be made larger with additional buffering.
2) the task has no deadline but should be completed as fast as possible. One example is network I/O.
3) the task has no time constraints at all. One example is loading soundfiles from disk: you don't really care how much time it takes, the only important thing is that it doesn't block other threads.
Supercollider's original "scsynth" Server has a thread for disk streaming (1) plus a thread for asynchronous tasks which includes outgoing network packets (2 + 3). The latter is not ideal, because it means that networking can be temporarily blocked by time consuming tasks. For this reason, the more recent "supernova" Server has a dedicated thread for outgoing network packets.
Christof
On 17.07.2021 14:45, Edwin van der Heide wrote:
Dear Giulio,
Am I right to assume that this would include writing arrays to disk without interfering with the audio thread?
Best! Edwin
On 16 Jul 2021, at 00:18, Giulio Moro via Pd-dev pd-dev@lists.iem.at wrote:
I have had this PR open for a while: https://github.com/pure-data/pure-data/pull/1261 . It adds threaded behaviour for disk and network I/O, making the Pd audio thread "real-time safer". I went through quite a few revisions courtesy of umlaeute and Spacechild1, but haven't heard from you directly. I am happy to do some more work if there is interest in merging. CI build currently fails because of weird "support" of ssize_t on VS (happy to hear about workarounds). Best, Giulio
Miller Puckette via Pd-dev wrote on 13/07/2021 19:22:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...) To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/). Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another. This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what? PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists cheers Miller _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Dear Christof,
Your distinction of the three categories makes a lot of sense.
Very nice to see the PR for the ‘asynchronous tasks API’ that provides a general infrastructure.
Best! Edwin
On 17 Jul 2021, at 15:49, Christof Ressi info@christofressi.com wrote:
Am I right to assume that this would include writing arrays to disk without interfering with the audio thread?
I don't think so, but there's already a separate PR for that: https://github.com/pure-data/pure-data/pull/1357
Actually, I am not sure what Giulio meant with "disk I/O". Maybe that the I/O thread could also be used to stream audio to/from disk? Personally, I would keep networking and audio streaming on different threads as they don't necessarily have the same priority.
---
Generally, I see three categories of worker threads:
1) the task has to meet a certain deadline. One example is streaming audio to/from disk: it eventually has to happen within a certain time frame, but the time frame can be made larger with additional buffering.
2) the task has no deadline but should be completed as fast as possible. One example is network I/O.
3) the task has no time constraints at all. One example is loading soundfiles from disk: you don't really care how much time it takes, the only important thing is that it doesn't block other threads.
Supercollider's original "scsynth" Server has a thread for disk streaming (1) plus a thread for asynchronous tasks which includes outgoing network packets (2 + 3). The latter is not ideal, because it means that networking can be temporarily blocked by time consuming tasks. For this reason, the more recent "supernova" Server has a dedicated thread for outgoing network packets.
Christof
On 17.07.2021 14:45, Edwin van der Heide wrote:
Dear Giulio,
Am I right to assume that this would include writing arrays to disk without interfering with the audio thread?
Best! Edwin
On 16 Jul 2021, at 00:18, Giulio Moro via Pd-dev pd-dev@lists.iem.at wrote:
I have had this PR open for a while: https://github.com/pure-data/pure-data/pull/1261 . It adds threaded behaviour for disk and network I/O, making the Pd audio thread "real-time safer". I went through quite a few revisions courtesy of umlaeute and Spacechild1, but haven't heard from you directly. I am happy to do some more work if there is interest in merging. CI build currently fails because of weird "support" of ssize_t on VS (happy to hear about workarounds). Best, Giulio
Miller Puckette via Pd-dev wrote on 13/07/2021 19:22:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...) To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/). Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another. This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what? PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists cheers Miller _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
What Christof is saying is right, my patch wouldn't affect disk I/O as it is. However, it provides infrastructure which could be reused to add threaded behaviour for disk I/O. I think currently only readsf~ / writesf~ use threaded disk I/O and they manage their own threads/locks. I think https://github.com/pure-data/pure-data/pull/1357 could also help with those. Apologies for the earlier misleading statement. Best, Giulio
sorry if that was misleading.
Edwin van der Heide wrote on 17/07/2021 16:30:
Dear Christof,
Your distinction of the three categories makes a lot of sense.
Very nice to see the PR for the ‘asynchronous tasks API’ that provides a general infrastructure.
Best! Edwin
On 17 Jul 2021, at 15:49, Christof Ressi info@christofressi.com wrote:
Am I right to assume that this would include writing arrays to disk without interfering with the audio thread?
I don't think so, but there's already a separate PR for that: https://github.com/pure-data/pure-data/pull/1357
Actually, I am not sure what Giulio meant with "disk I/O". Maybe that the I/O thread could also be used to stream audio to/from disk? Personally, I would keep networking and audio streaming on different threads as they don't necessarily have the same priority.
Generally, I see three categories of worker threads:
the task has to meet a certain deadline. One example is streaming audio to/from disk: it eventually has to happen within a certain time frame, but the time frame can be made larger with additional buffering.
the task has no deadline but should be completed as fast as possible. One example is network I/O.
the task has no time constraints at all. One example is loading soundfiles from disk: you don't really care how much time it takes, the only important thing is that it doesn't block other threads.
Supercollider's original "scsynth" Server has a thread for disk streaming (1) plus a thread for asynchronous tasks which includes outgoing network packets (2 + 3). The latter is not ideal, because it means that networking can be temporarily blocked by time consuming tasks. For this reason, the more recent "supernova" Server has a dedicated thread for outgoing network packets.
Christof
On 17.07.2021 14:45, Edwin van der Heide wrote:
Dear Giulio,
Am I right to assume that this would include writing arrays to disk without interfering with the audio thread?
Best! Edwin
On 16 Jul 2021, at 00:18, Giulio Moro via Pd-dev pd-dev@lists.iem.at wrote:
I have had this PR open for a while: https://github.com/pure-data/pure-data/pull/1261 . It adds threaded behaviour for disk and network I/O, making the Pd audio thread "real-time safer". I went through quite a few revisions courtesy of umlaeute and Spacechild1, but haven't heard from you directly. I am happy to do some more work if there is interest in merging. CI build currently fails because of weird "support" of ssize_t on VS (happy to hear about workarounds). Best, Giulio
Miller Puckette via Pd-dev wrote on 13/07/2021 19:22:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...) To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/). Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another. This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what? PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists cheers Miller _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Thanks for clarifying!
I think currently only readsf~ / writesf~ use threaded disk I/O and they manage their own threads/locks. I think https://github.com/pure-data/pure-data/pull/1357 could also help with those.
I don't think so. PR #1357 is about asynchronous tasks, which can take an arbitrary amount of time. Disk streaming, on the other hand, has to meet deadlines. Both have to be completely decoupled, otherwise you run into problems like this: https://github.com/supercollider/supercollider/issues/5511
---
my patch wouldn't affect disk I/O as it is. However, it provides infrastructure which could be reused to add threaded behaviour for disk I/O
That's actually an interesting idea. I think your patch could actually be generalized for different types of I/O:
1) "sys_registersocket" (-> "sys_registerfd") would also take the I/O type, such as "socket" or "file".
2) there would be a thread for each I/O type. Otherwise a send() on a TCP socket could block a read() on a soundfile, for example.
3) "poll_fds" would use the I/O type to determine if the fd is ready. For example, on Windows select() only works on sockets, but not on files!
4) The size of the ring buffer depends on the I/O type: for UDP sockets it must be large enough to hold the largest UDP packet; for disk streaming we actually want to be able to set the size ourselves, like the "buffer size" creation argument for [readsf~].
Just some ideas.
Christof
On 17.07.2021 23:26, Giulio Moro wrote:
What Christof is saying is right, my patch wouldn't affect disk I/O as it is. However, it provides infrastructure which could be reused to add threaded behaviour for disk I/O. I think currently only readsf~ / writesf~ use threaded disk I/O and they manage their own threads/locks. I think https://github.com/pure-data/pure-data/pull/1357 could also help with those. Apologies for the earlier misleading statement. Best, Giulio
sorry if that was misleading.
Edwin van der Heide wrote on 17/07/2021 16:30:
Dear Christof,
Your distinction of the three categories makes a lot of sense.
Very nice to see the PR for the ‘asynchronous tasks API’ that provides a general infrastructure.
Best! Edwin
On 17 Jul 2021, at 15:49, Christof Ressi info@christofressi.com wrote:
Am I right to assume that this would include writing arrays to disk without interfering with the audio thread?
I don't think so, but there's already a separate PR for that: https://github.com/pure-data/pure-data/pull/1357
Actually, I am not sure what Giulio meant with "disk I/O". Maybe that the I/O thread could also be used to stream audio to/from disk? Personally, I would keep networking and audio streaming on different threads as they don't necessarily have the same priority.
Generally, I see three categories of worker threads:
- the task has to meet a certain deadline. One example is streaming
audio to/from disk: it eventually has to happen within a certain time frame, but the time frame can be made larger with additional buffering.
- the task has no deadline but should be completed as fast as
possible. One example is network I/O.
- the task has no time constraints at all. One example is loading
soundfiles from disk: you don't really care how much time it takes, the only important thing is that it doesn't block other threads.
Supercollider's original "scsynth" Server has a thread for disk streaming (1) plus a thread for asynchronous tasks which includes outgoing network packets (2 + 3). The latter is not ideal, because it means that networking can be temporarily blocked by time consuming tasks. For this reason, the more recent "supernova" Server has a dedicated thread for outgoing network packets.
Christof
On 17.07.2021 14:45, Edwin van der Heide wrote:
Dear Giulio,
Am I right to assume that this would include writing arrays to disk without interfering with the audio thread?
Best! Edwin
On 16 Jul 2021, at 00:18, Giulio Moro via Pd-dev pd-dev@lists.iem.at wrote:
I have had this PR open for a while: https://github.com/pure-data/pure-data/pull/1261 . It adds threaded behaviour for disk and network I/O, making the Pd audio thread "real-time safer". I went through quite a few revisions courtesy of umlaeute and Spacechild1, but haven't heard from you directly. I am happy to do some more work if there is interest in merging. CI build currently fails because of weird "support" of ssize_t on VS (happy to hear about workarounds). Best, Giulio
Miller Puckette via Pd-dev wrote on 13/07/2021 19:22:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...) To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/). Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another. This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what? PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists cheers Miller _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I'd love to get a symmetric cos table for stable FM:
https://github.com/pure-data/pure-data/pull/106
But I remember you were thinking about going another direction entirely with osc~?
Thanks,
Matt
On Tue, Jul 13, 2021 at 1:23 PM Miller Puckette via Pd-dev < pd-dev@lists.iem.at> wrote:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I always found that [tabosc4~] along with ability to fill arrays using like csound gen message functions [sinesum( gives me all the accuracy I needed for FM. Am I missing something in pull/106 about shorcomings of [osc~]
andy
On Wed, Aug 04, 2021 at 10:55:02AM -0400, Matt Barber wrote:
I'd love to get a symmetric cos table for stable FM:
https://github.com/pure-data/pure-data/pull/106
But I remember you were thinking about going another direction entirely with osc~?
Thanks,
Matt
On Tue, Jul 13, 2021 at 1:23 PM Miller Puckette via Pd-dev < pd-dev@lists.iem.at> wrote:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next month or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go through small proxy objects; this will have to be done at load time I think) and to go back and try to figure out how to do tooltips without adding cruft to the inlet structure. (There's an ancient source-patch to provide tooltips by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to move a few functions from one file to another.
This might break some PRs, so... first of all would be to identify whatever PRs are ready to merge so I can do that before I make incompatible changes. Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Hi Andy, Thanks for the reply. sinesum is better but not perfect – the issue is that the cos() function is not the same on all four parts of the waveform, and those imperfections can cause fm to drift. You can build a symmetric table easily enough but since osc~ and cos~ are so important, they should be fixed. I'll submit a demo patch when I get home.
Matt
On Wed, Aug 4, 2021, 2:50 PM Andy Farnell padawan12@obiwannabe.co.uk wrote:
I always found that [tabosc4~] along with ability to fill arrays using like csound gen message functions [sinesum( gives me all the accuracy I needed for FM. Am I missing something in pull/106 about shorcomings of [osc~]
andy
On Wed, Aug 04, 2021 at 10:55:02AM -0400, Matt Barber wrote:
I'd love to get a symmetric cos table for stable FM:
https://github.com/pure-data/pure-data/pull/106
But I remember you were thinking about going another direction entirely with osc~?
Thanks,
Matt
On Tue, Jul 13, 2021 at 1:23 PM Miller Puckette via Pd-dev < pd-dev@lists.iem.at> wrote:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next
month
or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go
through
small proxy objects; this will have to be done at load time I think)
and
to go back and try to figure out how to do tooltips without adding
cruft to
the inlet structure. (There's an ancient source-patch to provide
tooltips
by Chris McCormichadn Guenter Geiger that I plan to start with - https://sourceforge.net/p/pure-data/patches/264/).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to
move
a few functions from one file to another.
This might break some PRs, so... first of all would be to identify
whatever
PRs are ready to merge so I can do that before I make incompatible
changes.
Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or
lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Unfortunately they can't be fixed by default (compatibility...) I'm still struggling to figure out how to best allow alternative tables (especially larger table sizes when needed) without badly complicating everything.
cheers M
On Wed, Aug 04, 2021 at 03:09:26PM -0400, Matt Barber wrote:
Hi Andy, Thanks for the reply. sinesum is better but not perfect – the issue is that the cos() function is not the same on all four parts of the waveform, and those imperfections can cause fm to drift. You can build a symmetric table easily enough but since osc~ and cos~ are so important, they should be fixed. I'll submit a demo patch when I get home.
Matt
On Wed, Aug 4, 2021, 2:50 PM Andy Farnell padawan12@obiwannabe.co.uk wrote:
I always found that [tabosc4~] along with ability to fill arrays using like csound gen message functions [sinesum( gives me all the accuracy I needed for FM. Am I missing something in pull/106 about shorcomings of [osc~]
andy
On Wed, Aug 04, 2021 at 10:55:02AM -0400, Matt Barber wrote:
I'd love to get a symmetric cos table for stable FM:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_...
But I remember you were thinking about going another direction entirely with osc~?
Thanks,
Matt
On Tue, Jul 13, 2021 at 1:23 PM Miller Puckette via Pd-dev < pd-dev@lists.iem.at> wrote:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next
month
or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go
through
small proxy objects; this will have to be done at load time I think)
and
to go back and try to figure out how to do tooltips without adding
cruft to
the inlet structure. (There's an ancient source-patch to provide
tooltips
by Chris McCormichadn Guenter Geiger that I plan to start with - https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_pure-... ).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to
move
a few functions from one file to another.
This might break some PRs, so... first of all would be to identify
whatever
PRs are ready to merge so I can do that before I make incompatible
changes.
Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or
lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Here's the demo – comparison between a 512 symmetric table and tabosc4~, a 512 cosinesum table and tabosc4~, and osc~ (512 linear interpolation).
I'm wondering, if this is a problem, is it a bug or just an alternative? Might affect how one thinks about compatibility.
On Wed, Aug 4, 2021 at 3:15 PM Miller Puckette msp@ucsd.edu wrote:
Unfortunately they can't be fixed by default (compatibility...) I'm still struggling to figure out how to best allow alternative tables (especially larger table sizes when needed) without badly complicating everything.
cheers M
On Wed, Aug 04, 2021 at 03:09:26PM -0400, Matt Barber wrote:
Hi Andy, Thanks for the reply. sinesum is better but not perfect – the issue is
that
the cos() function is not the same on all four parts of the waveform, and those imperfections can cause fm to drift. You can build a symmetric
table
easily enough but since osc~ and cos~ are so important, they should be fixed. I'll submit a demo patch when I get home.
Matt
On Wed, Aug 4, 2021, 2:50 PM Andy Farnell padawan12@obiwannabe.co.uk wrote:
I always found that [tabosc4~] along with ability to fill arrays using like csound gen message functions [sinesum( gives me all the accuracy I needed for FM. Am I missing something in pull/106 about shorcomings of [osc~]
andy
On Wed, Aug 04, 2021 at 10:55:02AM -0400, Matt Barber wrote:
I'd love to get a symmetric cos table for stable FM:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_...
But I remember you were thinking about going another direction
entirely
with osc~?
Thanks,
Matt
On Tue, Jul 13, 2021 at 1:23 PM Miller Puckette via Pd-dev < pd-dev@lists.iem.at> wrote:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the
next
month
or two. My personal priorities for this release would be putting
in a
message backtrace mechanism (by overriding canvas_connect and pd_bind to go
through
small proxy objects; this will have to be done at load time I
think)
and
to go back and try to figure out how to do tooltips without adding
cruft to
the inlet structure. (There's an ancient source-patch to provide
tooltips
by Chris McCormichadn Guenter Geiger that I plan to start with -
https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_pure-... ).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes
only
about 10 or 20% of the current that a Pi needs) I found out that I had to
move
a few functions from one file to another.
This might break some PRs, so... first of all would be to identify
whatever
PRs are ready to merge so I can do that before I make incompatible
changes.
Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of
localhost
generalize number/symbol box to allow displaying entire messages or
lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-dev mailing list Pd-dev@lists.iem.at
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
--
Hi Miller,
isn't this the perfect use case for the compatibility flag? Or do you think the change would be too invasive? After all, you have also changed the frequency response of [hip~] (Pd 0.44) and the behavior of the [stop( method for [line] (Pd 0.48).
I'm still struggling to figure out how to best allow alternative tables (especially larger table sizes when needed) without badly complicating everything.
If someone needs a sine wave oscillator with higher quality, they can simply use [tabosc~]. I don't think it's necessary to add anything to [osc~].
Just my 2c.
Christof
On 04.08.2021 21:15, Miller Puckette via Pd-dev wrote:
Unfortunately they can't be fixed by default (compatibility...) I'm still struggling to figure out how to best allow alternative tables (especially larger table sizes when needed) without badly complicating everything.
cheers M
On Wed, Aug 04, 2021 at 03:09:26PM -0400, Matt Barber wrote:
Hi Andy, Thanks for the reply. sinesum is better but not perfect – the issue is that the cos() function is not the same on all four parts of the waveform, and those imperfections can cause fm to drift. You can build a symmetric table easily enough but since osc~ and cos~ are so important, they should be fixed. I'll submit a demo patch when I get home.
Matt
On Wed, Aug 4, 2021, 2:50 PM Andy Farnell padawan12@obiwannabe.co.uk wrote:
I always found that [tabosc4~] along with ability to fill arrays using like csound gen message functions [sinesum( gives me all the accuracy I needed for FM. Am I missing something in pull/106 about shorcomings of [osc~]
andy
On Wed, Aug 04, 2021 at 10:55:02AM -0400, Matt Barber wrote:
I'd love to get a symmetric cos table for stable FM:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_...
But I remember you were thinking about going another direction entirely with osc~?
Thanks,
Matt
On Tue, Jul 13, 2021 at 1:23 PM Miller Puckette via Pd-dev < pd-dev@lists.iem.at> wrote:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next
month
or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go
through
small proxy objects; this will have to be done at load time I think)
and
to go back and try to figure out how to do tooltips without adding
cruft to
the inlet structure. (There's an ancient source-patch to provide
tooltips
by Chris McCormichadn Guenter Geiger that I plan to start with - https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_pure-... ).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to
move
a few functions from one file to another.
This might break some PRs, so... first of all would be to identify
whatever
PRs are ready to merge so I can do that before I make incompatible
changes.
Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or
lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Em qua., 4 de ago. de 2021 às 18:09, Christof Ressi info@christofressi.com escreveu:
isn't this the perfect use case for the compatibility flag?
I think it is; just my 2c also
I'm using that as rarely as I can, so far only for bug fixes. I don't think a limit on numerical accuracy is exactly a bug. I think it's nicer to most users not to have them have to bother with specifying a compatibility version.
cheers Miller
On Wed, Aug 04, 2021 at 11:09:06PM +0200, Christof Ressi wrote:
Hi Miller,
isn't this the perfect use case for the compatibility flag? Or do you think the change would be too invasive? After all, you have also changed the frequency response of [hip~] (Pd 0.44) and the behavior of the [stop( method for [line] (Pd 0.48).
I'm still struggling to figure out how to best allow alternative tables (especially larger table sizes when needed) without badly complicating everything.
If someone needs a sine wave oscillator with higher quality, they can simply use [tabosc~]. I don't think it's necessary to add anything to [osc~].
Just my 2c.
Christof
On 04.08.2021 21:15, Miller Puckette via Pd-dev wrote:
Unfortunately they can't be fixed by default (compatibility...) I'm still struggling to figure out how to best allow alternative tables (especially larger table sizes when needed) without badly complicating everything.
cheers M
On Wed, Aug 04, 2021 at 03:09:26PM -0400, Matt Barber wrote:
Hi Andy, Thanks for the reply. sinesum is better but not perfect – the issue is that the cos() function is not the same on all four parts of the waveform, and those imperfections can cause fm to drift. You can build a symmetric table easily enough but since osc~ and cos~ are so important, they should be fixed. I'll submit a demo patch when I get home.
Matt
On Wed, Aug 4, 2021, 2:50 PM Andy Farnell padawan12@obiwannabe.co.uk wrote:
I always found that [tabosc4~] along with ability to fill arrays using like csound gen message functions [sinesum( gives me all the accuracy I needed for FM. Am I missing something in pull/106 about shorcomings of [osc~]
andy
On Wed, Aug 04, 2021 at 10:55:02AM -0400, Matt Barber wrote:
I'd love to get a symmetric cos table for stable FM:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_...
But I remember you were thinking about going another direction entirely with osc~?
Thanks,
Matt
On Tue, Jul 13, 2021 at 1:23 PM Miller Puckette via Pd-dev < pd-dev@lists.iem.at> wrote:
(re-send - I had sent to pd-dev@iem.at but that now seems to be defunct...)
To Pd dev - I'm going to try to get the next Pd release (0.52) out over the next
month
or two. My personal priorities for this release would be putting in a message backtrace mechanism (by overriding canvas_connect and pd_bind to go
through
small proxy objects; this will have to be done at load time I think)
and
to go back and try to figure out how to do tooltips without adding
cruft to
the inlet structure. (There's an ancient source-patch to provide
tooltips
by Chris McCormichadn Guenter Geiger that I plan to start with - https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_p_pure-... ).
Before doing that I want to do some reorganizing - in porting Pd to FreeRTOS (so I can run it on an Espressif LyraT board, which I think takes only about 10 or 20% of the current that a Pi needs) I found out that I had to
move
a few functions from one file to another.
This might break some PRs, so... first of all would be to identify
whatever
PRs are ready to merge so I can do that before I make incompatible
changes.
Of course "stable development branch" first... then Dan's soundfile updates... then what?
PS more ideas of mine (among many): hot-reloading externs via a message to Pd use a "unix binding" socket between Pd and pd-gui instead of localhost generalize number/symbol box to allow displaying entire messages or
lists
cheers Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
On 05.08.21 03:56, Miller Puckette via Pd-dev wrote:
I'm using that as rarely as I can, so far only for bug fixes. I don't think a limit on numerical accuracy is exactly a bug. I think it's nicer to most users not to have them have to bother with specifying a compatibility version.
Maybe make the numerical accuracy a settable variable with the current depth as a default? (bonus: instant bitcrusher effect)
-
Alexandre Torres Porres -
Andy Farnell -
Chris McCormick -
Christof Ressi -
Edwin van der Heide -
Giulio Moro -
Iain Duncan -
João Pais -
Matt Barber -
Max -
Miller Puckette -
Winfried Ritsch