[PD] rj dirlib [was: Re: how to nqpoly?]

[Hans-Christoph Steiner]

On Nov 9, 2009, at 1:27 PM, Hans-Christoph Steiner wrote:

>
> On Nov 9, 2009, at 11:52 AM, Frank Barknecht wrote:
>
>> Hallo,
>> João Pais hat gesagt: // João Pais wrote:
>>
>>>> Depening on what kind of polyphonic patch you want to do, there are
>>>> some newer
>>>> alteratives to nqpoly4.
>>>>
>>>> If you want to polyphonize a simple midi instrument that accepts
>>>> pitch/velocity
>>>> pairs with [makenote] syntax, I'd recommend u_makepoly from the rj
>>>> library.  To
>>>> polyphonize oneshot instruments like drums, use u_robinpoly or
>>>> u_robinpolymono.
>>>>
>>>> All three come with extensive help files.
>>>
>>> ah, I didn't say that. basically there are simple synth patches  
>>> (with
>>> audio, all output for a main [throw~]) that take in lists with
>>> parameters. the lists come from a "score" of data structures  
>>> arrays (for
>>> now up to 6 parameters/arrays), at a rate of 100 a second. so I  
>>> guess no
>>> midi or oneshot type events. anyway I'll look at your suggestions.
>>
>> I guess, you could use u_robinpoly then. The difference is in the  
>> voice
>> allocation algorithm: u_makepoly uses the one from [poly] that  
>> relies on
>> makenote-like lists as parameters.
>>
>> But u_robinpoly just has a counter that counts modulo the number of  
>> voices
>> (i.e.  round-.robin polyphony). Every list you sent to robinpoly  
>> will be sent
>> to the next free voice unaltered (well, it will become a list- 
>> message, but you
>> can also directly send pointers for example). There is no effort  
>> whatsoever to
>> free voices, and as soon as all voices are taken, the first one  
>> will be reused.
>>
>>> unrelated: since you mentioned the rj library, I think it might be
>>> interesting (at least for me) to pack that library in pd-extended.  
>>> does
>>> this makes sense/is practicable for you guys?
>>
>> The rj-library is a moving target and gets new objects almost every  
>> week.
>>
>> Of course it's free software, so it could go into pd-extended, but  
>> I tend to
>> think of "rj" as something I came to call "dirlib" (i.e. the  
>> opposite of
>> "libdir").
>>
>> Because it is (almost) fully pd-vanilla, you can use it in a novel  
>> (or very
>> old) way: as a drop-in library that you just copy to whatever  
>> project directory
>> you are currently working on. (With RjDj this would be a Scene.) So  
>> a "dirlib"
>> is a library living in project directories. Just add [declare -path  
>> rj] to your
>> main pd file and that's it: you have a small, but at the same time  
>> very
>> powerful and fully documented musician's library right at your  
>> fingertips.
>>
>> [list]-abs is another example of such a "dirlib" you can use by  
>> copy-installing
>> it and adding a declare-ation. But as rj contains a minimal list- 
>> abs subset
>> this is only necessary in special cases.


I forgot to add, that you can also use any libdir in this manner that  
you describe above, dropping it into your project folder.  The only  
difference that I can see in your dirlib format as it stands now is  
that a libdir has a mylibrary-meta.pd file in it, and can be loaded  
like any other lib using [import], [declare] or "pd -lib" as long as  
you have the libdir loader.

.hc


>>
>> The advantage of the dirlib approach is, that this project  
>> directory will
>> continue to run on every Pd vanilla installation without any  
>> dependencies
>> outside of your project directory (with two tiny exceptions).
>
> Unfortunately, that's not true.  New versions of Pd-vanilla can  
> break this 'dirlib' approach too.  With the intro of a new object to  
> Pd-vanilla, any old object or abstraction in your lib that shares  
> that name will be blocked.  This is what we saw with the  
> introduction of [pow~] to Pd-vanilla.  Many people were using  
> cyclone's [pow~] before.  Since Pd-vanilla's pow~ is built into the  
> pd binary, there is no way to use an abstraction called 'pow~.pd',  
> and it even overrides pow~.pd_linux.
>
> For more info, check out my PdCon3 paper:
> http://at.or.at/hans/Let's_Make_Libraries_-_PdCon3.pdf
>
> The only way to maintain compatibility that has been proven is to  
> use the same versions of everything.
>
> .hc
>
>> So even if a later version of rj changes substantially, your old  
>> project with
>> the copy of rj *inside* continues to work as it always did. (As  
>> long as Pd
>> doesn't change too much, of course.)
>>
>> Ciao
>> -- 
>> Frank
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
>
>
>
>
>
>
> ----------------------------------------------------------------------------
>
> "It is convenient to imagine a power beyond us because that means we  
> don't have to examine our own lives.", from "The Idols of  
> Environmentalism", by Curtis White
>
>
>
>



----------------------------------------------------------------------------

"Making boring techno music is really easy with modern tools," he
says, "but with live coding, boring techno is much harder." - Chris  
McCormick