Never really needed fancy preset management other than storing messages in
a basic vanilla way. But I've seen people mention how Pd lacks a nice
preset system. Not that I know what a fancy one actually needs since I
never felt the demand. So I'm here to ask what people use in Pd Vanilla, be
it a pure vanilla solution or an external. And also to ask what people miss.
This is what I came up with as a pure vanilla abstraction, it's based on
[text] and [savestate]. Here's the thing:
https://drive.…
[View More]google.com/file/d/1A0ISEJo5F1E578WHM1doo1n2CJAthonU/view?usp=…
In short, the preset abstraction takes messages and stores them. You can
have many of these on your patch and use them to recall presets for any
parameters. It takes any kind of messages. I'm making use of built-in sends
and receives in the number boxes to make the patch cleaner. Just think that
you can have separate control of each parameter having its own preset or
group all of them together globally, or a group here and another there,
whatever... Once you save the patch, the presets you saved get stored in
the patch.
As for my current idea for my ELSE library, I'm using an object similar to
grab to take messages from [receive] objects. It's a development over this
original vanilla abstraction. My first draft is this, I hope that sharing
the screenshot give you a nice idea.
[image: Screen Shot 2021-01-21 at 04.47.42.png]
You can check what's up in my repository for more details...
https://github.com/porres/pd-else/blob/master/Classes/Abstractions/preset.pd
cheers
[View Less]
Hi folks, I'm on a vibe of uploading missing libraries and objects for Pd
Vanilla on deken. On the list I have FFTease, Lyonpotpourri, CICM-Tools and
more stuff that I'm looking into, just so you know...
Now, I see there's an old soundtouch~ external here:
http://www.katjaas.nl/pitchshift/soundtouch~.html - it's "version 0.9" by
Katja Vetter. It was developed with SoundTouch version 1.6 and Pure Data
version 0.42. I tested on Pd 0.51-4 32 bits on mac and it works fine. There
are binaries for …
[View More]download on the link above, but not for 64 bits. I wonder
if anyone wants to help me build these with pd-lib-builder and all.
Now, the ceammc librarym (and Pd-ceammc distribution) has a soundtouch~
external too. It's the same name, but not the same external, this one is
marked as "version 0.1". So we do already have "a" soundtouch~ for vanilla,
but I wanted to also get katja's external up there.
So I just uploaded the download from that page here
https://github.com/porres/pd-soundtouch - It's just the download as it is
and we need to change to hopefully use pd-lib-builder, which would make
things easier. I did try that and it didn't work.
So, anyone onboard with this?
cheers
[View Less]
Dear all,
I haven't posted anything on this list in years.
I'm trying to build a system to play several sound files in a loop,
each around 2 minutes in length, all at the same time. By "several" I
mean 10 to 15 different files. While I'd have no problem making a Pd
patch to achieve this, I have no idea what hardware I could use. I
have a limited budget, and I was planning on running Pd on a Raspberry
Pi (or similar single-board computer).
Is there any cheap way of outputing than many channels …
[View More]from a single
(a couple of) RPi ?
Thanks in advance,
Pierre.
[View Less]
Hello, as previously announced many times, we have an edition of the Vortex
Music Journal dedicated to Pure Data whose deadline is June 1st 2021!
Please share this around so it reaches people that might contribute!
2021 is the year Pd becomes 25 years old, hence the theme: “A quarter of
century of Pd: past, present and future”. So we're especially looking for
works that present a dialogue with Pd's history and also look ahead. Novel
works that contribute to Pd naturally do that, of course. And …
[View More]by "Pd",
clearly we mean all that is related and based on Pd, like forks, like works
that rely on libpd, etc... Note that artistic works are also highly
welcome, in the same way especially those that involve something "new".
for more details, see: http://vortex.unespar.edu.br/call_v9_n2a.pdf
[image: 153617156_10159099606851683_7070949421585107292_n.jpg]
_______________________________________________
Pd-announce mailing list
Pd-announce(a)lists.iem.at
https://lists.puredata.info/listinfo/pd-announce
[View Less]
Maybe I'm opening a can of worms, but I could imagine tabread etc taking an argument to specify which algorithm to use among a (small) list of those available. The current algorithm would be the default so as not to break existing patches. :)
I'm no expert, but if there are a known set of tried-and-true approaches, maybe they could added through a simple API. This is sort of how I refactored the soundfile type handling in the (as yet unmerged) soundfile object update branch: https://github.com/…
[View More]pure-data/pure-data/blob/0061a083e85ba2548668825b693a72f… <https://github.com/pure-data/pure-data/blob/0061a083e85ba2548668825b693a72f…>
> On May 3, 2021, at 3:37 PM, pd-list-request(a)lists.iem.at wrote:
>
> Message: 2
> Date: Mon, 3 May 2021 15:24:10 +0200
> From: Clemens Wegener <clemens(a)chair.audio <mailto:clemens@chair.audio>>
> To: Charles Z Henry <czhenry(a)gmail.com <mailto:czhenry@gmail.com>>
> Cc: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] 4-point interpolation changes timbre depending on
> sample rate
> Message-ID: <B6FDFF69-EE54-4F59-8234-5A53D086229C(a)chair.audio <mailto:B6FDFF69-EE54-4F59-8234-5A53D086229C@chair.audio>>
> Content-Type: text/plain; charset="utf-8"
>
> I think now would be a good place to pause the implementation and discuss
> if there is a need for this kind of algorithm in the PD community.
>
> We saw some use cases for the Whittaker-Shannon interpolation where
> we gain in quality and/or speed. Namely waveguides and pitch shifters.
>
> Is there anything else, where we would like to use this interpolation kernel?
> Like in general resampling?
> In the tabread~ for sample playback?
> Are there really quality or speed issues that we could solve there?
>
> For our use case the code I submitted is good enough. But I would be happy
> to spend more time optimizing if there is a need / a broad use of that algorithm.
> In that case we need another restructuring and some help from somebody
> who is very proficient in writing pd source code. :)
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]
Pierre,
You mention that the PD version of FCM is "in progress", but there is a
download on the site. Is that a beta version, or what is it's status?
Looking forward to giving it a spin!
b
---------- Forwarded message ----------
From: Pierre Alexandre Tremblay <tremblap(a)gmail.com>
To: pd-list(a)lists.iem.at
Cc:
Bcc:
Date: Thu, 20 May 2021 19:36:24 +0100
Subject: [PD] For those who like inspiring technical musicking talks
Dear all
The Fluid Corpus Manipulation (www.flucoma.org) …
[View More]project is the radar of
some of you, because it keeps cropping up once in a while. To make a long
story short, we have various machine listening and learning tools to help
tackle programmatically sound bank mining in Max and SuperCollider (and Pd
in progress) on MacOS, Windows and Linux with all the code open source...
As part of the project design, we commissioned works to get first users
feedback on interface decisions and directions and many other things. You
can see who was on the first cohort here (
https://www.flucoma.org/commissions/))
Now, in early July we have 8 more pieces coming. We asked all composers to
tell us how they (ab)used the tools. You can follow the saga [here](
https://discourse.flucoma.org/t/video-presentation-by-the-artists-second-se…)
and I'll post one per week, which leads us to the gigs. This week, Hans
Tutschku explains his approach to polyphonic piano processing, informed by
30 years of practice.
I hope you enjoy!
p
[View Less]
I agree. I think the current Pd-extended focused manual could be moved to a Pd-extended location for historical reasons. The "main" Pd FLOSS manual should be Vanilla + links or sections to active forks including the original Pd-extended manual. The current manual could then be refactored/updated and existing links would not be *terribly* broken.
> On May 31, 2021, at 12:00 PM, pd-list-request(a)lists.iem.at wrote:
>
> Message: 1
> Date: Sun, 30 May 2021 18:48:18 -0300
> From: …
[View More]Esteban Viveros <emviveros(a)gmail.com <mailto:emviveros@gmail.com>>
> To: Alexandre Torres Porres <porres(a)gmail.com <mailto:porres@gmail.com>>
> Cc: Pd-List <pd-list(a)lists.iem.at <mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] Pd FLOSS Manual, what to do with it?
> Message-ID:
> <CAJQqjJQCHRhc6mR4f==uoaJRGBCr3JgqfRZnK=o1W3-ofLmP-g(a)mail.gmail.com <mailto:CAJQqjJQCHRhc6mR4f==uoaJRGBCr3JgqfRZnK=o1W3-ofLmP-g@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> I think the best with Pd Floss is first to elucidate the community about
> Pd-Vanilla and the Forks. The name Pure Data Floss tutorial should be
> relayed in Pd-Vanilla only. In a historical Introduction, it can explain
> the history of creation of Pd, about Pd-Extended death, the actual
> situation and cite Pd forks, like Pd-ceammc and Purr-Data.
>
> After that we can update and even improve Pure Data Floss and it is. If
> Pd-ceammc and Purr-Data communities start thinking about creating a
> FLOSS for your distribution, they can do it with their proper names.
>
> This can avoid a lot of noise in the community and create an environment
> where everyone can choose the Pd software that best suits their needs.
>
> Cheers
> Esteban
--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>
[View Less]