[PD] Computer Aided Composition

ggkarman at musicologia.com ggkarman at musicologia.com
Fri May 27 23:15:35 CEST 2005


Hola,
> Hallo,
> josue moreno hat gesagt: // josue moreno wrote:
>
>> can anybody tell me or recomended some objects good for Computer Aided
>> Composition?
>
> Olaf Matthes' maxlib library has several useful objects for this,
> like objects for various random distributions, beat and rhythm for
> beat tracking. There are two borax'es available as well, one in
> maxlib, one in Cyclone, IIRC. PDContainer also is very useful to store
> and modify things like patterns etc. as can be "xeq".

I subscribe these. Some other favourites might be ann, chaos, pmpd..

>
> Data structures are a cool way to compose. Apart from the included
> docs there is a more basic tutorial by me as part of the pd~convention
> documentation and there is a spanish text about the same topic with a
> similar approach like my tutorial but covering things in much more
> detail. (I don't understand a word, only the pictures but judgung from
> your name you might be able to understand more than I do.) I don't
> have a URL handy, but it's in the list archive.

http://www.puredata.info/Members/ggkarman/Tutoriales/

>
> Generally however all these objects are rather low level. If you want
> "Band in a Box" you'll need to build this on your own - but that is
> most of the fun actually.

yep!
greg

>
> Ciao
> --
>  Frank Barknecht                               _ ______footils.org__
>
>           _ __latest track: "scans" _ http://footils.org/cms/show/41
>
>
>
> ------------------------------
>
> Message: 11
> Date: Fri, 27 May 2005 10:49:01 -0500
> From: chris clepper <cgc at humboldtblvd.com>
> Subject: Re: [PD] pixel data from pix_video
> To: Max Neupert <abonnements at revolwear.com>
> Cc: pd-list at iem.at, IOhannes m zmoelnig <zmoelnig at iem.at>
> Message-ID: <D863E5E2-CEC6-11D9-BE72-000393DBC2CE at humboldtblvd.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
>
>
> On May 27, 2005, at 9:55 AM, Max Neupert wrote:
>>
>> it is mentioned that pix_movie does not need to be textured which
>> sounds like an advantage first.
>
> It doesn't need the separate texturing object pix_texture like
> pix_film/video because all of the movie playing and texturing code is
> contained in one object.  On OSX this is an advantage since certain
> fast path texturing functions require tight control over execution
> order that can't be assured when using pix_film+texture.  On DV/SD
> material the difference is only a few percent per source, but on HD
> (1080 in particular) the gain can be 25% or more per source.  I have
> plans to work on a pixel format auto-detection for pix_movie that will
> help make sure the optimum path is used no matter what.
>
> cgc
>
>
>
>
> ------------------------------
>
> _______________________________________________
> PD-list mailing list
> PD-list at iem.at
> to manage your subscription (including un-subscription) see
> http://lists.puredata.info/listinfo/pd-list
>
>
> End of PD-list Digest, Vol 2, Issue 89
> **************************************
>





More information about the Pd-list mailing list