On 15 Feb 2016, at 01:09, Samuel Burt
<composer.samuel.b...@gmail.com
<mailto:composer.samuel.b...@gmail.com>> wrote:
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.
I'd say many other audio environments provide easy tools for
dynamics management, reverberation, and EQ. This creates a
particular sound for those environments. The fact that you have
to build these from scratch in Pd causes me to assume that the
easiest to build routines for these purposes would influence the
sound of neophyte patches, but as people develope more
sophisticated and original processes, there would be a
significant diverging of sonic characteristics between patches.
One final thing that might influence the "sound" of Pd or Max is
the use of whole numbers to represent frequencies and time values
that are determined in milliseconds. This might make a lot of
patches sound like they are based on the harmonic spectrum of 1Hz.
TLDR: If you want a more sophisticated sound, use line~ objects
to smooth signal rate control of audio processes, build your own
dynamics management, reverberation, and filter told, and make
sure to use a variety of floating point numbers or other special
ratios to determine frequencies and durations. At this point, I
don't think people could tell your sound came from Pd.
Message: 3
Date: Mon, 15 Feb 2016 00:27:08 +0200
From: Matti Viljamaa <mvilja...@kapsi.fi
<mailto:mvilja...@kapsi.fi>>
To: Pd-List <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>
Subject: [PD] Does Pd have a "sound"?
Message-ID: <d9a862c4-2f6e-4bfb-9d7d-b48a0dec5...@kapsi.fi
<mailto:d9a862c4-2f6e-4bfb-9d7d-b48a0dec5...@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 <anto...@metalu.net
<mailto:anto...@metalu.net>>
To: Pd-list <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>
Subject: Re: [PD] Nettles. Was: Cyclone: List of Issues with
existing
objects by Alexandre Porres
Message-ID:
<caocg5hwdcssryadkw9mq1qvv-livxdyfkvzyzav2e1mh7zn...@mail.gmail.com
<mailto:caocg5hwdcssryadkw9mq1qvv-livxdyfkvzyzav2e1mh7zn...@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 <mailto: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
<brbrof...@gmail.com <mailto:brbrof...@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
<i...@vt.edu <mailto:i...@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 <i...@vt.edu
<mailto:i...@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 <tel:%28540%29%20231-6139>
> i...@vt.edu <mailto:i...@vt.edu>
> www.performingarts.vt.edu <http://www.performingarts.vt.edu/>
> disis.icat.vt.edu <http://disis.icat.vt.edu/>
> l2ork.icat.vt.edu <http://l2ork.icat.vt.edu/>
> ico.bukvic.net <http://ico.bukvic.net/>
> On Feb 14, 2016 8:40 AM, "Fred Jan Kraan"
<fjkr...@xs4all.nl <mailto:fjkr...@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
<por...@gmail.com <mailto:por...@gmail.com>
> <mailto:por...@gmail.com <mailto:por...@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 <mailto: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 <mailto: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 <mailto:Pd-list@lists.iem.at> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list@lists.iem.at <mailto: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 <mailto: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
****************************************
