If anything Pd's sound would be related to its 64 sample block size that is mostly evident when people don't use sample rate line~ objects to smooth their signals.
Message: 3
Date: Mon, 15 Feb 2016 00:27:08 +0200
From: Matti Viljamaa <mviljamaa@kapsi.fi>
To: Pd-List <pd-list@lists.iem.at>
Subject: [PD] Does Pd have a "sound"?
Message-ID: <D9A862C4-2F6E-4BFB-9D7D-B48A0DEC5A82@kapsi.fi>
Content-Type: text/plain; charset=utf-8
Do you think Pd has a characteristic sound to it? Or whether discussion board threads claiming Pd (and Max) have a distinct (and not good) sound just have people who haven’t listened to good patches?
-Matti
------------------------------
Message: 4
Date: Sun, 14 Feb 2016 23:32:18 +0100
From: Antoine Rousseau <antoine@metalu.net>
To: Pd-list <pd-list@lists.iem.at>
Subject: Re: [PD] Nettles. Was: Cyclone: List of Issues with existing
objects by Alexandre Porres
Message-ID:
<CAOCG5HwDcssRYAdkw9MQ1QvV-LivXDYfkVzYZaV2E1mH7znv0Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I've only partially followed all this discussion (not using Max myself),
but maybe an object I wrote could help you building such abstractions :
[moonlib/dinlet~] is an [inlet~] with an init float value (constant signal)
as an argument.
This default value is overloaded when a signal is connected to the inlet,
but restored when the signal is disconnected. A float sent to it would
overwrite the default constant value.
Of course the init default value could be one of the abstraction's
arguments ($xxx)...
BUT :
- there is a very little hack (which could be called a bugfix...) that has
to be made to pd source (this change is written in comment in the source
file of dinlet~). I should open a ticket for that in the sourceforge repo.
The involved bug is mixing the different float values up when [dinlet~] is
used together with normal [inlet]s.
- I should add a missing feature in dinlet~, which would add an inlet to
the [dinlet~] object itself, to allow changing the default value inside of
the abstraction.
If anyone think this would be helpful, I could do this (open a ticket and
update moonlib about this missing inlet).
2016-02-14 20:29 GMT+01:00 Jonathan Wilkes via Pd-list <pd-list@lists.iem.at
>:
> > Why not simply have an inlet that can handle both inside an abstraction
> and route signal one way and number the other and then sprinkle that with
> dynamic nlet creation and you're done? Then you can simply abstract most
> cases.
>
> I read (and like) your spec on dynamic nlet creation, but I have a problem
> with section 2.1 Signals:
>
> "To handle the dynamic creation of signal inlets and their routing within
> the abstraction, the implementation must"
>
> It looks like the rest of the section is missing. :)
>
> -Jonathan
>
>
>
>
> On Sunday, February 14, 2016 1:51 PM, Matt Barber <brbrofsvl@gmail.com>
> wrote:
>
>
> I tried coding that once, but it seemed like it needed some big change in
> architecture. Technically it's only the main signal that accepts both
> messages and signals in this way, where you would want to route the
> message. Floats should almost always be promoted to signals.
>
> On Sun, Feb 14, 2016 at 1:18 PM, Ivica Ico Bukvic <ico@vt.edu> wrote:
>
> Why not simply have an inlet that can handle both inside an abstraction
> and route signal one way and number the other and then sprinkle that with
> dynamic nlet creation and you're done? Then you can simply abstract most
> cases.
>
>
> On 2/14/2016 11:36 AM, Matt Barber wrote:
>
> [gt~] is a great example of something that could work as an abstraction,
> except for the pesky right inlet which should take a signal if there's no
> creation argument, but float otherwise.
>
> On Sun, Feb 14, 2016 at 10:50 AM, Ivica Bukvic <ico@vt.edu> wrote:
>
> What I am also trying to do eventually in pd-l2ork is weed out redundant
> objects and only keep the ones that do the said task the best while still
> supporting other objects' idiosyncrasies (if any). There is absolutely no
> reason to have multiple objects of the same kind. Ultimately, one could
> keep all the externals in the same folder and completely do away with all
> the declares, imports, and other things that make learning pd unnecessarily
> harder.
> --
> Ivica Ico Bukvic, D.M.A.
> Associate Professor
> Computer Music
> ICAT Senior Fellow
> Director -- DISIS, L2Ork
> Virginia Tech
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> ico@vt.edu
> www.performingarts.vt.edu
> disis.icat.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net
> On Feb 14, 2016 8:40 AM, "Fred Jan Kraan" <fjkraan@xs4all.nl> wrote:
>
> Hi Alexandre,
>
> guess some of it is in:
> http://fjkraan.home.xs4all.nl/digaud/puredata/cyclone/cycloneToDo.html
>
>
> This list is also becoming a list of what has been done.
>
>
> As with _nettles_
>
> "try to resurrect as independent object library"
>
> Anyway, tell me if this gets includes on this file.
>
>
> Yes, the nettles-objects are part of the latest cyclone versions. They are
> part of the nettles library, which can be loaded with [declare]. Not all
> operating systems like the '<' and '>' in the object names and there is
> overlap with other library objects, so only loading them when needed is
> cleaner.
>
>
> cheers
>
> ps. count me in for help with the help files
>
>
> Great!
>
> Greetings,
>
> Fred Jan
>
>
> 2016-02-11 22:18 GMT-02:00 Alexandre Torres Porres <porres@gmail.com
> <mailto:porres@gmail.com>>:
>
> Howdy, it's a known fact brazilians will start the year only after
> carnival, so here I am.
>
> I'd like to share my list of things to do with existing Cyclone
> Objetcs. Obviously there might be other issues with other objects
> that would make them up to date with the current version of Max (Max
> 7). Nonetheless, this is what I find relevant, and I've been really
> checking it through.
>
> It's only about 11 objects, some has already been discussed here and
> might have been fixed or in the process to be taken care of, forgive
> me if so.
>
> I have it attached and also as a link to a google doc
>
>
> https://docs.google.com/document/d/1L_dUNgznfhaZHPKMJ3jJ_p9uIXRVP6Rs9-3nXy2Qlk8/edit?usp=sharing
>
> Next, I will get together a list of new objects I think should be
> included, many of which I've already made as abstractions (kind of
> to show how it works like I did with [teeth~], cause I really think
> they should all be done as externals).
>
> Cheers
>
>
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> <http://lists.puredata.info/listinfo/pd-list>
> http://lists.puredata.info/listinfo/pd-list
>
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> <http://lists.puredata.info/listinfo/pd-list>
> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160214/68d50002/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Pd-list mailing list
Pd-list@lists.iem.at
to manage your subscription (including un-subscription) see
http://lists.puredata.info/listinfo/pd-list
------------------------------
End of Pd-list Digest, Vol 131, Issue 45
****************************************