@porres You are reading way to much into it, I did not say or imply those things, sorry if it came off that way. Lets just purge this who digression from the thread, I will start.

@porres The else load message which prints to the log as shown in Balwyn's screen shot. Curiously I just noticed that my older version of else does mention [declare]

• ALSO NOTE: Loading this binary did not install the ELSE library
  you still need to add it to the "preferences=>path"
  or use [declare -path else]

@Balwyn It is always fun trying to explain complex patches especially when dynamic patching is involved. It was the $0s in the main patch combined with my lack of knowledge regarding soundfonts/working with binary files in pd which instigated my question, you have it 99% of the way there to be an abstraction and it really looks like you intended it to be an abstraction but then left it as a patch, so I got curious. I probably just read into habitual $0 usage, most people seem not to use them unless they have a reason to do so.

@Balwyn That is what I thought but your use of $0 made me doubt myself, I am not great with the audio rate stuff in pd.

@porres Shouldn't your ALSO NOTE regarding paths be to use [declare] or at least mention it, using paths just causes headaches when you share a patch or ask for help.

@Balwyn Is there a reason this is a patch and not an abstraction? Am I missing some nuance which makes an abstraction not work here or did you just leave it as a patch because it was an exercise? Your use of $0s suggests you intended it to be an abstraction but you left it as a patch.

@suresh That patch is corrupted somehow, that block of objects stuck in the middle of the connect messages should not be there, should be before the connect messages. This might work but may not, object order may still be screwed up. I don't have Mr Peach installed so don't know if this is enough to fix it or what.

#N canvas 10 10 600 400 10;
#X obj 10 10 declare -lib mrpeach;
#X obj 100 100 loadbang;
#X msg 150 150 440;
#X obj 150 200 f;
#X obj 150 250 osc~;
#X msg 250 150 0.5;r
#X obj 250 200 *~;
#X obj 250 300 dac~;
#X obj 350 100 mrpeach/udpreceive 8000;
#X obj 350 150 mrpeach/unpackOSC;
#X obj 350 200 oscparse;
#X obj 350 250 route /frequency /amplitude;
#X obj 350 300 f;
#X obj 350 350 f;
#X connect 1 0 2 0;
#X connect 2 0 3 0;
#X connect 3 0 4 0;
#X connect 4 0 6 0;
#X connect 5 0 6 1;
#X connect 6 0 7 0;
#X connect 6 0 7 1;
#X connect 15 0 16 0;
#X connect 16 0 17 0;
#X connect 17 0 18 0;
#X connect 18 0 19 0;
#X connect 19 0 4 0;
#X connect 18 1 20 0;
#X connect 20 0 5 1;

Your font issue might just be you think font setting should apply to all patches? Patches save their own font size to make sure patch layout does not turn into a mess. In your patch the last number of the first line is the font size for that patch, so if you change #N canvas 10 10 600 400 10; to #N canvas 10 10 600 400 18; that patch will use an 18 pt font instead of 10. The command line/preference setting only affects newly created patches.

@suresh These days the best way to deal with externals is to install them via deken (help menu -> find externals) and create them in the patch either with path ( [mrpeach/cd4011] ) or declare the library in the patch ( [declare -path mrpeach] ) which lets you call them just as [cd4011] without the path. This makes sure your patch will work with most pd installs which have Mr Peach installed and if it does not you will know exactly what library is missing by the declares or by the errors printed to the console which will say 'couldn't create mrpeach/cd4011' instead of just 'couldn't create cd4011' which leaves us guessing what it is, is it the object form the mrpeach library or a local abstraction or cd4011 from some other library? Adding paths for each library you install tends to create headaches down the road. Perhaps this is what you have tried?

I am just offering best practices and a shot in the dark, don't really know Windows, that is David's area.

@raynovich I am not sure what you mean by sendlocal and sendreceive but the rest of your post suggests you are just talking about send and receive? If so we had a thread about that recently, send and receive are a bit less efficient than wires but generally should not be an issue.

@the.sasa Like this?
iits-help.pd
iits.pd

List dripping in one form or another tends to be the solution when you have to deal with both a stream and a list, Sticking a [change] between the [t f f] and [get $1( would make this more efficient, will update it later.

Edit: Added the [change] and tweaked the get message so it will play well with older versions of pd.

@vulturev1 Processing the input can help a great deal with [sigmund~] jumping around but how to best go about this depends on what your input is and what you want on the output. When I was using [sigmund~] a lot I found filtering, frequency multiplication and compression all to be useful for getting stable output, especially frequency multiplication. I always found it easier to address the problem on the input instead of the output.

Simple abstraction exploiting the somewhat recently added [file] object, just run it with the file name as argument (without .pd extension) and it will open it for you and delete itself. Pleasant side effect of opening files this way is that it does not pollute your recently opened file menu with those files you just want to take a quick peak at. Requires iemguts.
open.zip

@paulwasthere That is enjoyable, simple and nothing fancy but enjoyable, I have a fondness for music which goes no where and is in no rush to get there. The background noises work well with it. I think PureData actually has a large number of users but a rather inactive online community, lots of clues pointing that way at least.

@cfry Sure, make a master patch which controls everything and send [open filename filepath( to a [s pd]. In each patch have a common receive the master patch sends a bang to when it wants the patch to close which causes the patch to send [menuclose( to its canvas through the usual methods (sendcanvas, namecanvas, pdcontrol, etc). You could also do it as a chain with no master patch, each patch opening the next and then closing itself at the appropriate times but that could be troublesome in some situations. WIthin limits opening and closing patches could work well but will get complex quickly compared to subpatches and [switch~].

Edit: actually sending {menuclose( will require you to use [namecanvas] in the patch and send [menuclose( to that canvas name from the master patch or the next opened patch in the case of chaining the open and close, other ways will cause pd to crash.

@cfry I think I would use subpatches for each variation and turn them on and off with [switch~], simpler logic. May also have to disable message rate stuff but that is simple enough.

@ben.wes Does OSX have /proc/ or something like it where devices can be written too? Would mean you can just use [command] to write to the appropriate file. Or perhaps OSX has a command for this which you can run from [command]? Have not used OSX to any real extent since 10.2 so no idea how far it has strayed from its BSD roots.

@whale-av They are serial with signal branching off between so were probably playing with phase, possibly a yet implemented/sorted out or dropped feature. But my explanation was mostly a joke and not the sort of joke which will carry well over the internet with its very broad and global demographic. I was reliving the experience of making the first abstraction that I shared, I wish it was as clean as @izecake's, I seem to have gone out of my way to obfuscate the useless operations it contained.

@dreamer They are clearly vestigial from when the abstraction's logic was being sorted out and were probably deleted and brought back many times and their deletion or addition often breaking the abstraction for some incomprehensible reason; they served no purpose and you stared at the before and after for an embarrassing amount of time trying to figure out why it works with such a useless operation that does nothing until you finally see the obvious and delete them once and for all. Then you realize you actually needed a [* 0.5] there, so you put it back and nothing works even though a [* 0.5] should not break anything, just decrease volume or something, but nothing works. Back to staring for an embarrassing amount of time. Delete them, still doesn't work. Put them back and make them [* 1], works. More staring. Learn not to tempt providence and call it good enough. Finally realize what is going on and fix the actual problem but really don't want to tempt providence, just want to make music, so leave them. Isn't this the standard pd work flow? I have at least one [* 1] or [+ 0] or the like in most of my patches.

@izecake Fun stuff, I still have my old DD-3 delay sitting about for doing this the old fashioned way. Couple notes, add a $0 to you delay names so you can have multiple instances of abstraction in use without multiply defined errors, [delread~ $0glitch 50] and [delwrite~ $0glitch 500] or the like. Once you do that your [print] is going to irritate you, nice information but every instance of the abstraction is going to print it and spam the log when you load that patch with 83 instances of your abstraction. Make it a comment so people can open the abstraction and instantly know what it is even if they don't have the help file.

@atux I would open up the help browser and start learning data structures, this is a perfect use for them an a good beginner project to learn with. The data structures section help patches have gotten to be good enough that there is no longer a reason to fear and avoid data structures.