Also, take a look at this:

https://lists.puredata.info/pipermail/pd-list/2019-07/125556.html

Check on the Pure Data Facebook group, and on the PD mailing list, as there are more likely to be announcements there. You do find workshops sometimes, but you'd be lucky to find one at the right place and right time.

But don't be discouraged from learning PD if you can't find a workshop. There are lots of good resources available online, and lots of friendly people willing to help. I remember thinking that I wouldn't be able to learn it without a teacher, but once I pushed through the initial hurdles, teaching myself became easy and enjoyable.

Hello @cmovvv, sorry for not seeing your post at the time! You're right that Context doesn't work yet on 0.49 Windows 64. I'm working on getting it fixed, but as you can see, I haven't been putting much time into it recently**. In the mean time, you should be able to download all of the externals yourself and then run Context off of those. There is information in the readme on how to do this. Otherwise, running it on 0.48 should also work fine.

Don't give up, and let me know if you need any help. I'm more likely to see messages if you join the Facebook group or email me.

**But I am putting lots of time into developing a new standalone version of Context in C++.

Check out http://www.martin-brinkmann.de/pd-patches.html. There are some nice drones here, although the patches are a bit hard to follow.

If you want to make your own, I'd suggest creating multiple layers. One filtered sawtooth on its own can sound rough, but four or five tuned to a chord can be much richer. Also, don't rely on the basic [lop~] object. Use [bob~] or some other external filter.

Depending on what you're doing, you could also use [max] to establish a floor for the argument value.

[loadbang]
|
[f $1]
|
[max 7]
|
...

PD now has an external package manager built in, so go to Help --> Find Externals and search for what you want. However, in Windows, the latest version of Vanilla, 0.49, became 64bit, which automatically makes most of the 32bit externals listed on the repo inaccessible (which is really annoying). If you're good at compiling you could try to compile them for yourself. Once it's compiled, tell PD the location of the directory (Preferences --> Path) and you should be good to go.

If all you want to do it pitch tracking, have a go with Vanilla's native [sigmind~] first.

By accident I ended up listening to both of @seb-harmonik.ar's tracks at the same time, and it sounded pretty good, lol. If you can't find what you're looking for in any particular track then maybe this is the right approach.

This won't meet all of your criteria, but you should also check out Robert Henke a.k.a. Monolake, if you haven't already. His earlier and later works are all pretty radical, though ambient, The stuff from his middle period tends to be more club oriented. Layering Buddha is probably my favorite ambient piece of all time.

http://www.roberthenke.com/releases/recordings.html

Ie. try this:

I'm 90% sure that it is not possible to test for a connection in Vanilla. But if you don't mind using externals, then there is [iemguts/canvasconnections].

You can type into those number boxes too--you just have to press Enter afterwards.

Have you turned DSP on? Top-right corner of the PD console.

There is an example Shepard Tone in 3.audio.examples --> D09.shepard.tone.pd which might be of help.

Not sure exactly what the difference is between Shepard tone and Risset...

[makefilename] will work fine, but in this case there is really no need for it, as you can just put the symbol inside the message box like this:

[200(
|
[pack f $0]
|
[read resize $2-audio $1(

Message boxes don't interpret $0. Instead, you have to pass $0 to them as an argument.

[o]
|
[f $0]
|
[read $1-array(

@bocanegra this isn't working for me because of a broken object named [ar~]. Is this a custom abstraction that you forgot to attach?

I'm glad it's useful to you! Please let me know if you have any other problems or suggestions--I'm always trying to make it better. (There's a Facebook group for this kind of feedback, if you're interested).

One other trick with [mover]--if you hold Shift and double-click, on the object, then you will shift it by block sizes. This is often easier if you're just trying to get it to fit the Overlay box.

Well you might be right, but my audio patches tend to run heavy already and I don't want to stress them any further. I guess that I also just like doing things in the non-signal domain. LarsXI's first solution is quite simple and effective and only uses one more object than the [snapshot~] method would, so I think I'll be going with that!

Short answer: no. Obviously it must cost something, but I don't recall ever having seen or heard of a patch where the performance was affected by the overuse of [spigot]. Use it to your heart's content!

Also check out the new [savestate] object in Vanilla 0.49 for working with abstractions!

Oh snap, I built #2 years ago, it was just broken! It's fixed now, and the git is up to date. @palaver, please have a go and tell me what you think.

@palaver
I've been working on the "fit" command recently, and it should be working a lot better on the latest version of Context, which you can download here. There is also a new option at the bottom of the Content properties menu, "fit to overlay", which saves you having to write the command. However, it doesn't seem to be working yet as a creation argument, ie. [content fit] should jump to the right position and size, but doesn't. Hopefully I'll fix this soon.

[mover] is frustrating to begin with, but it works well when you get used to it. The trick is to realize that the selectable area is just outside the borders of the box, by about 5 pixels. If the [content] object is up against the wall of the Overlay, you still need to move the mouse in position just past the border. Of course, all this needs to be done when the Shift key is held down.

Dragging and dropping will probably never work as well in Context as on "real" software, but perhaps I can still make it better. Two things that I've been wondering:

1. Should the selectable area be moved to inside the [content] object border? Would this make it more intuitive to use?
2. It would be nice if the [mover] changed colour to indicate that it is in the right position to move the embedded object. I'm going to take a look at this, though I suspect that it won't be easy.

Do you have any other suggestions?