@Muology: Just answering to the second part for now ... for generating all combinations of 2 elements, this here will do (subpatch pd iterate_list is on the right. should probably be an abstraction ... and the result is not logically ordered).

if you want to create all combinations with arbitrary lengths, it can certainly be done in a similar manner and I'm pretty confident that one could find an abstraction (or external) for this somewhere. I didn't find one yet though and I'd need a little more time and focus to build it, I'm afraid.

list2pairs.pd

Just a quick question in this context - would this here be a valid way of comparing performance? I found the difference between the until, sel and route versions quite interesting:

@oid oh, nice! and much better than my approach. wasn't aware that there was a delete method. thanks!

... here's another approach expecting a list input: shuffle-list.pd
I guess the loop management (stopping when all values are handled) could be done better - but I'll leave it like this for now.

Thanks for posting - this is certainly a nice little challenge to work on! I approached this some time ago by removing random parts of a list until it's empty. Now that you posted here, I thought that the [text] objects might even make it a bit easier. So here's another approach (maybe a little overkill to use these objects ... but it works - reset is done after each generated row and you can change the range on the right): shuffle-text.pd

@whale-av thanks a lot for the quick response! I guess I'll give up on these names then (although aesthetically I prefer the separating periods to underscores or hyphens - but that's obviously not an argument anymore). so it's going to be "perlin_3d~" etc. in the future... acceptable enough.

Hey all, I recently switched from Windows to macOS and really enjoy patching there a lot. There's one thing that's quite annoying though and after lots of useless googling and support chats, I felt like people here might have answers:

I built quite a few abstractions for my own use and some of them follow names like perlin.3d~. To keep files and folders a little organized, I place abstractions in folders with the same name. So in this case, the actual abstraction is placed in path_to_externals/perlin.3d~/perlin.3d~.pd.

This worked pretty well for my Windows setup. And it also basically works on macOS. But I'm using Dropbox to sync my Pd stuff and in this case, syncing doesn't work - the folder doesn't sync back to Dropbox and Finder alerts inside the folder that Dropbox encountered an unexpected error. items may be out of date. Dropbox support says it's an Apple problem and Apple until now says this is "somehow" connected to temporary file conventions and they can't do anything about it.

So here are my questions:

• Are these names bad practice for Pd abstractions?
• Is there a better way to organize them other than through folders like this?
• Am I the only one experiencing this? (Please no!)

@jameslo : I'm joining the conversation here since I was that one attendant @alexandros is mentioning!
I doubt there is a recording since the conference tool said "not recording" and the organizers were not present for the whole time. So if the 2 of us don't have a recording, there probably isn't any. But it was a great introduction (thanks again, @alexandros!) and if you didn't do so already, I can really encourage you to check out the examples that are in the folder of the neuralnet external (which is available through deken). @alexandros: are you planning to update the version with the minor fixes that you've added (iirc - although I think those were documentation fixes)? Or is the repo on https://github.com/alexdrymonitis/neuralnet more up-to-date compared to the deken version?