Hi, this is conTorchionist (or its embryonic version, I would say):
https://github.com/ecrisufmg/contorchionist
It's a project that is in its very early stages, but I thought it was worth
announcing here, not so much for its current development stage, but because
it might be useful to others and also as a thank you to the community and
the developers who have created inspiring tools. Besides, obviously, Pure
Data, SuperCollider, and Python, I'm referring to libraries like FluCoMa,
timbreID, nn~, librosa, and others, which have been fundamental to the
development of conTorchionist.
Briefly, the idea is to have a nomadic and flexible library, based on
libtorch, that allows for the use of the same DSP (machine listening, but
also, in the future, other things related to synthesis/signal processing)
and ML processes in both real-time (PD, Max, SC) and non-real-time
(Python). Wrappers for other languages/environments should not be so hard
to code, as everything is interfacing a shared library (and libtorch shared
libraries). Another key idea is to have a widely used tool like
PyTorch/libtorch/torchaudio as a foundation, which greatly facilitates
development and integration with existing ML+ML experimentation workflows
and processes. The structure is heavily inspired by FluCoMa, but it is
probably simpler and follows a logic of core Processors and wrappers in
different languages (we have been prioritizing Pure Data, but we are
gradually creating things for Max, SC, and Python as well). Since we use
libtorch, conTorchionist also has some other potentially interesting
features, like using the GPU for calculations and DSP - CUDA
(Windows/Linux) or MPS (Apple Silicon).
We are taking it slow, so a lot is still missing (documentation, testing,
etc.). That's why we haven't published a versioned release or binaries yet.
We hope to do so soon after verifying the consistency of some things
regarding DSP calculations in PyTorch / torchaudio (which, in turn, use
librosa as a reference) and ensuring that the initial wrappers compile
properly on various operating systems (we have tested mainly on Linux and
macOS, so it's likely that some adjustments will be needed in the
CMakeLists for Windows).
I hope it will be useful and that we can gradually make things more
organized. At the moment, it's just me and a great student (Vinícius
Oliveira), plus some always quite hallucinatory and unreliable AI bots. ;)
The paper we presented this week, on SBCM, is here:
https://www.researchgate.net/publication/395473005_conTorchionist_A_flexibl…
Or if you prefer figures: https://ecris.cc/2025sbcm_contorchionist-slides/
<https://ecris.cc/2025sbcm_contorchionist-slides/>
Any feedback is appreciated, of course!
Best regards!
José Henrique Padovani
Hello,
I am happy to announce two websocket externals: [wsserver] and [wsclient]
The externals support binary and text-data.
Both externals are statically linked using OpenSSL 3.5.2 and Boost.Beast
1.88.0
Be aware: It uses the recently introduced function "pd_queue_mess" and
therefore needs Pd >= 0.56.0.
Please find it on deken for Linux, macos and Windows or on github:
https://github.com/i-n-g-o/websockets-pd
Cheers,
Ingo
Hello,
I am happy to announce an update to Rabbitcontrol for Pd.
Most notably version 2.0 handles threading properly and solves a bug on
macos by switching to Boost.Beast.
Be aware: It uses the recently introduced function "pd_queue_mess" and
therefore needs Pd >= 0.56.0.
It now comes as statically linked individual externals instead of one
library.
OpenSSL got updated to 3.5.2 and it is using Boost in version 1.88.0.
Getter functions are now prefixed with "get" to allow parameters like
"max", "min", "order", etc.
Please see the changelog for more details:
https://github.com/rabbitControl/pure-rabbit
The formerly included websocket externals got moved into their own
project. I will announce it in an extra email.
It is up on deken for Linux, macos and Windows if you want to try it out.
(Search for: rabbitcontrol, rabbit or rcp)
If you wonder what RabbitControl is you can find some information here:
https://rabbitcontrol.cc/
Cheers,
Ingo
Hi, lots of people have been reporting issues with ELSE and Pd 0.56. I had
things sorted before this Pd release but I had to wait and wrap up an
update. Next week I'll be attending the PdMax conference and I now have a
test release ready! I plan to upload the actual final one by september 2nd!
This is just to see if people find issues with it...
By the way, Pd 0.56-1 is out with some important bugfixes, and this
actually needs it! It's already up in deken but you can also find a
download here. I'm owing a Raspberry pi release. I need help with that
actually...
Check the link for the details on what's new. I'll make another
announcement with the highlights when the final version is officially out.
https://github.com/porres/pd-else/releases/tag/v.1.0-rc14-test
Please download and open All_else_objects.pd - see if all the objects will
load just fine. Tell me if you see something funny. Thanks!
cheers
To Pd-announce:
Pd version 0.56-1 is available from https://msp.ucsd.edu/software.htm
or (source only) via github: https://github.com/pure-data/pure-data
This fixes a problem in 0.56-0 which could prevent Pd from starting up on
macintoshes on which the menus were not in the English language,
along with several other problems for all platforms.
cheers
Miller
thanks Rolf,
yes I noticed the plot errors, I've just managed to clear them (I'll fill
an issue about this maybe, and about some other data-structures problems,
e.g there's a crashing bug when using text fields in pre-allocated arrays).
The solution I found is to delete-then-recreate the subpatch containing the
problematic "element" template (here [pd template-bar], and [pd
template-mark] for the timeline).
As for the name... yeah, I don't like [wavview/wavview_timeline] either. It
should probably just be [wavview/timeline], but I didn't like the idea of a
naming clash with other possible [timeline] libraries. OTOH that won't
happen without [declare -path wavview].
In that case I have to use [wavview/timeline] in the help patches (so that
you can copy/paste it anywhere else), so I'm gonna refactor my repo and put
the patches in a wavview/ subdir (and add a hidden [declare -path ..]).
Maybe I will overwrite v0.3 in Deken.
EDIT: done. I replaced v0.3.
Antoine
sidenote: I experienced a mail rejection when I first answered to rolf. The
error was:
<pd-list(a)iem.at>: host mailgate.iem.at[193.170.191.178] said: 550 5.1.1
<pd-list(a)iem.at>: Recipient address rejected: undeliverable address:
host
mail.iemnet[192.168.171.25] said: 550 Please use pd-list(a)lists.iem.at
instead. (in reply to RCPT TO command) (in reply to RCPT TO command)
so I redirected to pd-announce(a)lists.iem.at, hope it works now.
Le jeu. 14 août 2025 à 18:36, Antoine Rousseau <antoine(a)metalu.net> a
écrit :
>
> thanks Rolf,
>
> yes I noticed the plot errors, I've just managed to clear them (I'll fill
> an issue about this maybe, and about some other data-structures problems,
> e.g there's a crashing bug when using text fields in pre-allocated arrays).
> The solution I found is to delete-then-recreate the subpatch containing the
> problematic "element" template (here [pd template-bar], and [pd
> template-mark] for the timeline).
>
> As for the name... yeah, I don't like [wavview/wavview_timeline] either.
> It should probably just be [wavview/timeline], but I didn't like the idea
> of a naming clash with other possible [timeline] libraries. OTOH that won't
> happen without [declare -path wavview].
> In that case I have to use [wavview/timeline] in the help patches (so that
> you can copy/paste it anywhere else), so I'm gonna refactor my repo and put
> the patches in a wavview/ subdir (and add a hidden [declare -path ..]).
>
> Maybe I will overwrite v0.3 in Deken.
>
> Le jeu. 14 août 2025 à 12:29, <rolfm(a)dds.nl> a écrit :
>
>> hi antoine,
>>
>> this version of wavview is giving plot errors when the containing patch
>> is closed.
>>
>> it happens also when closing the help-patches.
>>
>>
>> something i don't understand:
>>
>> i can create the object [wavview],
>>
>> but for the timeline i have to do [wavview/wavview_timeline]??
>>
>>
>> thanks for your work,
>>
>> rolf
>>
>>
>>
>> Antoine Rousseau schreef op 14-08-2025 1:16:
>>
>>
>> v0.3 is out!
>>
>> The scrollbar is now draggable, as one could reasonably expect.
>>
>> As well, the zooming center is now chosen by the position of the first
>> click, as usual with this kind of interface.
>> However, since on Pd we don't have the mouse-up information (so
>> unfortunate!), a trick requires the user to release Shift and press it
>> again before restarting zooming (otherwise the previous zooming center is
>> used).
>>
>> A "timeline" object has also been added.
>> It is synchronized with the wavview of the same name, and displays evenly
>> spaced time markers. It also displays the time at the left and right bounds
>> of the currently visible interval. The design isn't that great, but, hey,
>> it does its job.
>>
>>
>> Le dim. 10 août 2025 à 00:41, Antoine Rousseau <antoine(a)metalu.net> a
>> écrit :
>>
>>> thanks Roman, hopefully it can find its way into netpd :-)
>>>
>>> 2 days, and already a new version 0.2!
>>> Besides a couple of bugfixes and optimizations, you can now use an
>>> instance of wavview, privately to a specific table, for caching the peak
>>> buffers, so that another instance can instantly access the pre-calculated
>>> data and display it with minimum overhead.
>>>
>>> Le ven. 8 août 2025 à 22:54, Roman Haefeli <reduzent(a)gmail.com> a
>>> écrit :
>>>
>>>> On Fri, 2025-08-08 at 19:56 +0200, Antoine Rousseau wrote:
>>>> >
>>>> > I'm pleased to present 'wavview', a single-file-abstraction waveform
>>>> > viewer.
>>>>
>>>> I'm very pleased to hear about this. For a long time I've been missing
>>>> a good waveform display. I tried to do something similar¹, but yours is
>>>> way better. And it is astonishingly smooth to edit.
>>>>
>>>> Thanks for sharing.
>>>>
>>>> Roman
>>>>
>>>> ¹
>>>> https://github.com/reduzent/netpd-instruments/blob/main/abs/rh_wavedisplay.…
>>>> ---
>>>> pd-list(a)lists.iem.at - the Pure Data mailinglist
>>>>
>>>> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/7LWVSIKLC…
>>>>
>>>> To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list
>>>> UNSUBSCRIBE and account-management -> https://lists.iem.at/
>>>
>>>
>> ---
>> pd-list(a)lists.iem.at - the Pure Data mailinglist
>>
>> https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/I5G47ZSPI…
>>
>> To unsubscribe send an email to pd-list-leave(a)lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.iem.at/
>>
>>
Hi,
I'm pleased to present 'wavview', a single-file-abstraction waveform viewer.
It is fully "vanilla" (no external dependencies) and built with data
structures.
I have tried to make it versatile and easily integrable into more
higher-level applications or components: no connection is required and the
title is hidden.
It displays the content of a table, and allows you to zoom/scroll through
the data, select a range, and set a single-point index (e.g playback
position). This can be done by sending messages, or via interaction with
mouse and modifier keys.
The drawing consists of as many vertical segments ("bars") as there are
pixels in the width of the object. Each bar goes from the minimum value to
the maximum value among the samples contained in the interval represented
by the bar, so that peaks are always displayed correctly, regardless of the
zoom factor.
An additional optimization is performed, which computes several subsampled
min-max tables in advance; this significantly reduces the number of
calculations required to compute a single bar, especially with large tables.
It's available on Deken, just search "wavview".
Feel free to report issues or requests there:
https://github.com/metalunet/pd-wavview
(there's also a small animated gif demo in the front page).
p.s: wavview requires Pd 0.56 to run, because it uses the new 'goprect'
message.
Antoine Rousseau