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.

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).

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

Hallo, jurgen hat gesagt: // jurgen wrote:

rj-lib doesn't seem to be part of pd-extended. I didn't see a link on
your footils site either. sourceforge search renders no results. just
where is the library available?

Ah, sorry, it belongs to RjDj and can be downloaded either as part of the RjDj Composer Pack: http://trac.rjdj.me/ or with subversion as: $ svn co http://svn.rjdj.me/scenes/trunk/rjlib/

Browse it here: http://trac.rjdj.me/browser/trunk/rjlib

Ciao

Frank

FYI, to use it with Pd-extended, drop the 'rj' folder into your user- specific path: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files-with...

Then you can load them like [rj/u_robinpoly]. If you add a rj-meta.pd
file inside of that 'rj' folder, then you can load it as a lib, i.e.
[import rj] and [u_robinpoly].

.hc

On Nov 9, 2009, at 12:52 PM, jurgen wrote:

thanks! and that was fast!!! Jurgen

On Nov 10, 2009, at 1:41 AM, Frank Barknecht wrote:

...

Hallo, jurgen hat gesagt: // jurgen wrote:

...

rj-lib doesn't seem to be part of pd-extended. I didn't see a link
on your footils site either. sourceforge search renders no results.
just where is the library available?

Ah, sorry, it belongs to RjDj and can be downloaded either as part of the RjDj Composer Pack: http://trac.rjdj.me/ or with subversion as: $ svn co http://svn.rjdj.me/scenes/trunk/rjlib/

Browse it here: http://trac.rjdj.me/browser/trunk/rjlib

Ciao

Frank

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

All information should be free. - the hacker ethic

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%27s_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@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

On Nov 10, 2009, at 3:47 AM, Frank Barknecht wrote:

Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

...

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

The important aspect is that the rj dirlib has (practically) no
external dependencies. You cannot just drop e.g. "mapping" into your project
directory the same way. You first have to install pd-extended or or something
similar. The rj dirlib OTOH can be used with plain, extended or condensed
distributions of Pd. Freedom of choice.

Definitely. I think its good to have a diverse Pd ecosystem. I want
to support that. The big disadvantage is incompatibilities. So when
its easy like in this example, then we should do the bit of work to be
compatible. The dirlib approach so far seems like a simple subset of
the libdir approach, so that's a good thing. If people who use
dirlibs just stick a 'mylib-meta.pd' file in it, then people can
choose between the two approaches without changing anything.

Of course, libs depending on libs is harder question. I think we can
make it work for both the dirlib and libdir approach. This is how I
see it working:

myproject-
|-rjlib |-mapping |-purepd

Then it should be possible for objects in myproject/mapping to find
objects in myproject/purepd. Currently, there seems to be some issues
with that. If anyone can think of any, please add it to the relevant
wiki pages here:

http://puredata.info/dev

Then we can use them when implementing the library ideas as discussed
at the last PdCon.

.hc

Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war on
terrorism. - retired U.S. Army general, William Odom

On Nov 9, 2009, at 2:42 PM, Claude Heiland-Allen wrote:

Hans-Christoph Steiner wrote:

...

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.

Sure, but can't you still use -lib to load your own pow~.d_fat in Pd
since 0.42 (which would print "warning: renamed old pow~ to
pow~_aliased" or similar)? Or am I completely missing the meaning
of those printouts?

I am not positive how that mechanism works. Based on my understanding
of it, you could force it to load a particular object class (i.e.
cyclone's pow~) using the pd -lib technique you mention, provided that
object class is a binary, and not an abstraction. If the problem
involved an abstraction being overridden by a pd internal, you are
shit-out-of-luck.

So its not really a solution to the aforementioned problem. There are
other issues with that aliasing technique as discussed in the
archives. For these reasons, the auto-aliasing is disabled in Pd- extended 0.42.5, but we still need to figure out how to deal with the
new pd-internal [pow~] and its conflict with cyclone's [pow~].

...

The only way to maintain compatibility that has been proven is to
use the same versions of everything.

Exactly - no need to care too much about backwards compatibility,
because you could always use pd-0.38-devel for your old patches and
pd-0.43-guirewrite for your current patches and pd-0.44 for your
next decade patches...

The missing piece here is an auto-upgrade tool for pd patches,
similar to what lilypond uses:

http://lilypond.org/doc/v2.9/Documentation/user/lilypond/Updating-files-with...

Personally, I think we can improve the situation quite a bit, that's
why I wrote that paper for PdCon. Of course, sticking to the same
versions of everything is the only guarantee, but we can do a lot to
avoid incompatibilities.

The simplest one is making it so that externals and abstractions
included in the same folder as a patch have precedence over all
others, including pd-internals. That way you can stick your own
[pow~] in the same folder as your project, and you'll always know its
your [pow~] in use.

.hc

You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie

On Nov 14, 2009, at 4:26 AM, Claude Heiland-Allen wrote:

Hans-Christoph Steiner wrote:

...

For these reasons, the auto-aliasing is disabled in Pd-extended
0.42.5,

Elsewhere I read that *.d_fat (etc?) external names are disabled too.

The code related to this stuff was so ugly I couldn't get it working
in Pd-extended. If anyone wants to try, they can do it. But the
point remains, on Mac OS X the .d_fat/.d_ppc stuff is an ugly kludge
no Mac OS X does things this way, everyone uses universal binaries
with a single extension (i.e. .pd_darwin).

Is there a list of pd-vanilla features that are missing in pd- extended?

Those are the only two I know of. They are only related to how things
get loaded. And I strongly advocate, and have for a long while now,
removing both of these from Pd-vanilla.

And a list of pd-extended features that are missing in pd-vanilla?

You can see the list of patches included in pd-extended. Something
more readable and details would be nice, but currently doesn't exist.
If someone wants to create something better, I'll contribute. I just
don't have a good idea how people want to see this info, since I just
look at the included patches.

http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/packages/patches...

Also, there is the NextRelease page on the site which is the TODO and
ChangeLog for the currently developed version. That info then gets
included into the ChangeLog for each release.

http://puredata.info/dev/NextRelease

.hc

All information should be free. - the hacker ethic

Depening on what kind of polyphonic patch you want to do, there are some
newer alteratives to nqpoly4.

hi, some more development about this. I've been trying the rjlib, and I
think it doesn't suit me. what I have are events with x duration (as
example between .1 - 5 sec), which are fed parameters read from data
structure arrays at the speed of 10ms. So, one "note" receives each 10ms a
list of parameters, until it's finished. It would be like I had a midi
note down, and would change a controller. But if I got it right, these
poly patches are made to handle oneshot events. Is there a way of making
sure that pitch x goes to synth x, with the parameters attached?

Attached is an excerpt of the score. 6 parameters for each event, and
these last for ~1.5 secs.

About nqpoly5 and 6: does [initbang] still exist? I don't have it in
pd-ext, and replacing it with [init] doesn't work. the connections on the
dynamic patch aren't created in the right places.

João

Maybe you don't need any poly-clone at all? What you describe sounds as
if a simple pool of objects could serve you just as well. E.g. with voice.pd
you

I was coming slowly to that conclusion. maybe I could also do without a
dynamic voice creator, probably I won't be using that many voices.
instead, a router that memorizes voice activity/idleness should be enough.
I'll have a look.

...

Attached is an excerpt of the score. 6 parameters for each event, and these last for ~1.5 secs.

Ah, I think the attachment is missing. :)

of course it is, it makes no sense to do it right when you can do it wrong.