Lurked for a while, first post now.

I've been using Max/MSP pretty heavily since last December, and I've fallen in love with the visual coding paradigm. For a variety of reasons PD appeals to me more than Max (though I did get used to the bells and whistles). I've replaced all my hardware effects (loopers, stompboxes, synths, sequencers) with max patches, and I'd be comfortable enough making the same over again in PD, but I'm having trouble translating a few objects that I relied on heavily in Max.

Umenu is a big one, the ability to receive numbers and output corresponding text comes in handy with scripting lots of objects, and routing sends and receives. It's ease of populating, rewriting, and deleting of entries makes many complex tasks easily manageable. It also functions as a great label when I hid things away. I suspect there's an equivalent method, but nothing leaps out. Should I be looking at some sort of coll type object? Struct?

In the DSP realm, I'm a little worried not to see Rate~ or some analog of it. I use phasor~ to control my loops, and Rate~ works magic on polymetric sequences. I could probably rig up a similar system scaling and wrapping a signal, but straight up Rate would be best.

In order to be able to slot effects in and out of different parts of the signal chain, I've been using combinations of bpatchers and polys, with scripting to switch between different stompbox abstractions. I found the graph on parent option, but it doesn't seem (at least not obviously) that I can use scripting on it to call up different subpatches. Please correct me if I'm wrong.

I think those three might just cover it (at least for the time being). I've found the externals pulled from the max library to be an amazing resource, and between overlapping objects, manuals, and the answers on this forum most of what I need to know is readily available. If those objects lack analogs in PD I may just bite the bullet and get into java/c/python...at the moment I have no experience with text based programming, but I'm just looking for an excuse, really.

I'll be hitting the manuals cover to cover as best I can in the morning, but I'd be glad to have my patches running sooner all the same.

All help is much appreciated.

Aa

There is an object in Pd-extended called [popup] that is similar to [umenu], though it's not as flexible. It's also really tricky to call it's helpfile using the right-click menu (it's mouse interaction doesn't get turned off in edit mode), but if you just make an object called [popup-help] it will load as an abstraction.

I haven't found anything like [rate~] yet. If you want to subdivide a [phasor~], though, you can easily do it like this:

[phasor~]
|
[*~ 4] <-- number of subdivisions
|
[wrap~]

Making it longer is tricky, and I have been working on an abstraction that does it. But I'm not fully satisfied with it yet. Generally, though, when using a [phasor~] clock I tend to make the [phasor~] as long as I need for sample-accuracy and just subdivide it.

Check out help browser -> Manuals -> pd-msg for the documented scripting in Pd. The documentation is a bit incomplete, but it should be enough to get you started. Search the forum for dynamic patching or throw up a question in Technical Issues if there's something specific that's not covered there.

There is an object in Pd-extended called [popup] that is similar to [umenu], though it's not as flexible. It's also really tricky to call it's helpfile using the right-click menu (it's mouse interaction doesn't get turned off in edit mode), but if you just make an object called [popup-help] it will load as an abstraction.

I haven't found anything like [rate~] yet. If you want to subdivide a [phasor~], though, you can easily do it like this:

[phasor~]
|
[*~ 4] <-- number of subdivisions
|
[wrap~]

Making it longer is tricky, and I have been working on an abstraction that does it. But I'm not fully satisfied with it yet. Generally, though, when using a [phasor~] clock I tend to make the [phasor~] as long as I need for sample-accuracy and just subdivide it.

Check out help browser -> Manuals -> pd-msg for the documented scripting in Pd. The documentation is a bit incomplete, but it should be enough to get you started. Search the forum for dynamic patching or throw up a question in Technical Issues if there's something specific that's not covered there.

Thanks Maelstrom, that's a huge help. The biggest difficulty I've had so far is with documentation, really. Little things like scope~ needing to be written [Scope~] was a bit confusing, but PD works great. Popup looks good, and ought to do the trick.

I've looked into wrap~, and though it might be easier if it could accept wrapping arguments like max's pong~, I can surely force it into those ranges otherwise.
Making things longer surely will be a stumbling block, translating might not be so easy :S.

I've also realized there aren't any dsp conditionals, like >=~. I'd been using edge~ to convert phasor~'s zero crossings into bangs for a step sequencer and I can't think of any accurate equivalent (snapshot would be far too grainy).

Also wondering about matrix~, is the table method the only way? envelope style graphing works for monophonic, but I was hoping to do a monome/tenori-on type thing (actually the first thing I learned in max) and it seems significantly more difficult.

Are there externals I will need that aren't included in the recent PDextended release? Also wondering if anyone here is familiar with jMax, and if so if it would have the objects I'm looking for in an open source format. Will I need to tackle OSC to get these functionalities outside of Max?

@Orkester said:

Little things like scope~ needing to be written [Scope~] was a bit confusing, but PD works great.

Since [Scope~] is an external, it may have been to avoid a nameclash with another [scope~] external. Just speculating, though.

I've looked into wrap~, and though it might be easier if it could accept wrapping arguments like max's pong~, I can surely force it into those ranges otherwise.

There is a [pong~] clone in Pd-extended.

I've also realized there aren't any dsp conditionals, like >=~.

Well, they actually do exist, but there were issues with them loading properly in Pd-extended. You can use [expr~ $v1>=$v2] as an alternative. [expr~] is one of those objects not included in Max that you may find yourself using all the time (unless you were using the external).

Also wondering about matrix~, is the table method the only way?

I don't know of a [matrix~] equivalent in Pd, but you definitely have all the objects you need to build it. I think you actually mean [matrixctl], though? Most people just line up a bunch of [tgl]s to make that kind of interface.

That's one of the things you'll likely find when moving from Max to Pd. Pd-vanilla doesn't have as many high-level objects as Max/MSP, but most of them have counterparts in Pd-extended or can be built with what Pd offers.

Are there externals I will need that aren't included in the recent PDextended release?

That depends on what your needs are.

Also wondering if anyone here is familiar with jMax, and if so if it would have the objects I'm looking for in an open source format.

I've never used jMax, but I do know that it was just recently brought back from the dead after a few years of no development and, so, needs to rebuild its community. I would say "not likely."

Will I need to tackle OSC to get these functionalities outside of Max?

That also depends on what your needs are.