@dxinteractive [vcf~] might give you the filters with a bit of extra work for highpass.
[pack] might be useable instead of [list]...... but is it the list selector that is unrecognised?
Even a raw message like [1 2 3( ....... that is a list, has the list selector added in Pd.
David.

Hello,

I tried to post this to the Pd mailing list but for some reason it didn't go through. I'll repost it here.

Hi list,

[namecanvas foo]

[traverse foo, bang(
|
[pointer]
|
[$1, $1 two(
|
[print]

Currently, evaluating the binbuf "$1, $1 two" will silently fail to output anything. That's clearly wrong.

Now, consider this:

[namecanvas foo]

[traverse foo, bang(
|
[pointer]
|
[print]

Here, the outgoing pointer calls the pointer method of the [print] object. There are many other objects which have a defined pointer method.

So if we want the behavior to be the least surprising as well as the least likely to cause bugs, the "$1" above should be equivalent to just sending the output from [pointer].

That would mean that a message box that expands to a single gpointer should trigger the pointer method for the target object (i.e., the object the message box connects to). That will ensure it triggers the pointer methods for classes which define one, as well as triggering the default Pd pointer handling for classes which don't.

This change seems pretty needed. I see all kinds of patches in the wild where users are doing weird things in object chains to handle pointers. It appears these users are hitting this bug and just pentesting the message until the gpointer finally flows out of the message box. (Which can happen with "list $1", or even "wtf $1" with a list split and trim following it.)

The remaining question is what to do about "$1 two."

It would be nice to convert it to a list in that case. That would match the behavior of Pd messages with leading numbers, as well as keeping with the common knowledge that Pd messages begin with a symbolic selector (or at least an implied one). However, gpointers break that pattern because there was no "pointer" selector reserved, implied or otherwise, in Pd. Thus, arbitrary messages beginning with the selector "pointer" can be followed by arbitrary arguments which in no way imply a gpointer payload. For example, "pointer 50 25" can be sent to [route pointer] which will happily output "50 25".

That means that going forward there's no way to reserve "pointer" in the way that, say, "float" is reserved. For example, if you try to type "float boat" in a message box Pd will tell you that "boat" is a bad argument for the "float" message. It's not allowed. And if we made a requirement that only a gpointer arg may follow the "pointer" selector it would probably break some existing patches in subtle ways.

So there are only two sensible behaviors left:

1. Error out in message boxes for a multi-arg message that has a gpointer selector
2. Call pd_anything to handle the "$1 two" example above.

I guess the determining factor would be whether multi-arg messages with interspersed gpointers are currently being used at all. Unfortunately, they probably are since [struct] will output messages like "click (gpointer) 50". Simply using a [route click] will then output a multi-arg message that has a gpointer selector.

That means Pd is already implicitly supports sending around "(gpointer) arg1 arg2 etc." messages to arbitrary objects. And I assume that any future crashers from that would be fixed. So it's probably no worse to allow message boxes to forward on such messages using pd_anything.

Thoughts? If not I'm probably going to start building some tests for this and
implement it in Purr Data after the next release.

-Jonathan

@Hugo Legrand thanks a lot. i downloaded the file "ml-0.17.0-alpha-WIN32.zip" from this link: https://github.com/cmuartfab/ml-lib/releases somehow the windows build contains only 2 .pd objects (ml.svm-help and ml.zerox-help) but a lot of .dll´s. i added the library path to the search path and the name to start processes and pd prints can´t load library. the 2 objects are recognized but only half of the messages do work. so i am not sure if i do something wrong, or if the build does not work (for me). i tried it with the osx build, in comparison to windows build the library get loaded on startup but everything else seems the same.
this are the printed messages if i click every help-file message from ml.svm-help.pd:
ml.svm: Support Vector Machines based on the GRT library version 0.2.5 revision: 2-Jan-2017
error: ml.svm: messages with the selector 'bang' are not supported
error: ml.svm: function not implemented
error: ml.svm: messages with the selector 'bang' are not supported
error: ml.svm: messages with the selector 'normalise' are not supported
error: ml.svm: function not implemented
ml.svm: new input vector size, adjusting num_inputs to 4
error: ml.svm: class label must be a positive integer
error: ml.svm: messages with the selector 'predict' are not supported
error: ml.svm: messages with the selector 'estimates' are not supported
error: ml.svm: messages with the selector 'load' are not supported
error: ml.svm: messages with the selector 'save' are not supported

Well, pd's messages are weird. I haven't looked, but I kinda assume the code is inefficient as using a single message is slower than using a [list prepend ] -- [list trim ] combo.

This bears repeating because it is the opposite of what you would probably intuit.

Messages are slower than the list objects.

This might change, as the list objects are new compared to messages, but the code for messages probably has to sanitize a lot more inputs than the list objects...
Also fyi, the prepend and append objects are part of the cyclone library and are not part of vanilla.

The reason why you would use the list objects rather than messages really just comes down to pd's semi-explicit typing. Some objects need to know what kind of input is coming so they need a selector like list, symbol, float, set, etc. Other objects just interpret whats coming at them so they don't need a selector.

UPDATE:

WOW!!! Things have really kicked into high gear, including but not limited to the following:

I built the container for the keyboard:

out of an old board-game box ("Guess Who" game);

made the pedals from (borrowing from Pierre at Guitar Extended) some old Lego Duplo blocks I had;

secured/made a ballast/elevated the backend for the box using wooden blocks I had from when my kids were younger;

secured the whole thing using wood-glue and duct tape.

The "pedals" include in the following arrangement (will include pics prob tomorrow after the final gluing dries):

across the top:

dsp(on|off) (2 small wooden blocks), (the following are from stacks of 3 2x4 legos) bender- (red), benderselect (yellow), bender+ (blue);

bottom section (each made from 6 (in a brick) 2x4 legos): typeselector (red), select- (yellow), select (green), select+ (blue), bypass (black).

Am working on the logic currently to include:

dsp (obvious) (is also going act as a fail-safe in case anything gets out of control);

the benders will: take a single parameter on an effect and incr- or decr-ment it, with the middle button to set the parameter;

the bottom section, will do the same as the bender except

the left-most (red) pedal will

if held (hid key_val=2) longer than x time, set the selectors to adjust the overall sound (i.e. which effects go into which of the 7 slots) by setting a value to between 1 and 10 then selecting that preset;

if held (hid key_val=2) longer than y time, set the selectors to
1 select which slot I want to adjust, meaning the effect in that slot;
2 select a preset (between 1 and 10) for the above slot.

the black-bypass will

depending on the current value of CurrType (Arrangment or Slot), bypass either the whole setup or the Current Slot.

Total Cost for the Whole setup: <10$ and lots of blood and sweat.

note:
Though no tears! (Well, except maybe that 45 minutes I spent in my bathtub with all the lights out, wondering what in the hell point there was to my "work" after I had seen MMB's "gui.eq7.mmb~" (which I very quickly dubbed "The God Filter"). (2 weeks later I had learned enough to implement it

afterward:

When I first (now coming up on nine months ago) saw Pierre's website, I knew, just KNEW, a guitar effects pedal/rack had been put in the reach of not only me, but ANYbody who had little-to-no money if they were just willing to put in the effort.

-peace.
svanya

Hardcoded limitations are annoying indeed. The next version of sliceplay~ will have a selector 'minspeed' so the user can change the minimum absolute playback speed at will. The minimum is there because if you accidentally set speed zero, playback of a slice will never end until the patch is closed, and the object is effectively blocked.

The next sliceplay~ version also has a selector 'interrupt' with option 0 (never interrupt a slice playback), -1 (only interrupt reversed playback) and 1 (interrupt always allowed), with a short fade-out of the interrupted slice to prevent clicks. The next version of slicerec~ has a selector 'start' for manual start of slice record, in case you want to include a sound without clear attack.

These things are written, and built/tested on OSX this weekend. Builds for other platforms must still be done, plus a modified version of the demo patch. I'll upload the stuff soon as all is ready.

Katja

You won't be able to do it without some wires (but no 300). The example shows how I would do it.

http://www.pdpatchrepo.info/hurleur/audio.path.selector.pd

[polygate~] can do what [selector~] does and then some. The patches posted above work more in line with [selector~]. [polygate~] is probably more computationally expensive than the above patches, so unless all that crossfading is necessary, your probably better off with something like what we gave you.

As for [groove~], it can also be made in Pd, though it would definitely require a little more craftiness than [selector~]! It shouldn't be too difficult though. It's mainly a table being looked up with [phasor~] + [tabread4~] with the [phasor~] being scaled within loop points.

By the way, if you're not already aware, you can look at Max/MSP's documentation online here:

http://www.cycling74.com/docs/max5/vignettes/intro/docintro.html

It might help a little.

i knew as soon as i published this patch that i would find a problem with it. here's the problem--when you use the selector to switch arrays...the phasor~ that drives the tabread4~ does not recalibrate. i am working on this and hope to a fix soon, plus some other feature i am adding.

hilbert~