A little ridiculous, had to jump through some hoops to get that symbol back into a float. I used the -u flag of [fudiparse] so I could just use a simple [list split] in an earlier version but [fudiparse] and [fudiformat] should drop in now. There is some external which would make the symbol to float conversion easier but I can never remember which one it is and I have been trying to figure out the logic of why some float symbols will not convert with [float] and they weirdly are not even consistent regarding which hoops you have to jump through, first time I had to form a list and put it into a [text].

What about implementing your own fixed or floating point encoding for sysex? Break the float into two ints at the decimal, first first bit of the message is the length of the first int, reconstruct after the fudiparse?

Edit: Suppose a simple integer based fp implementation would not actually work here, did not think that through.

@Vnms nope, no python knowledge required, you just run the script with the output of the web app as args and it gives you what you need to stick into [biquad~].

@Vnms I have used https://github.com/drmartinjaros/biquadgraphpd for calculating this stuff, makes it simple and might help you find your flaw and should work better than ChatGPT.

@gentleclockdivider manual or help files or here on the forum, too long ago to recall. Seb gives the full answer above, I put it in pd terms since most (including myself) find pd far easier to understand than pd's dense C.

Regarding Max's join, make it, just an abstraction away. [list store] mostly does that and a great deal more.

@gentleclockdivider Yeah, will fix that error. The first inlet in the case of [pack] is always a list, a float or symbol is just a list of one element list. Internally [pack] works like this:

So left inlet will always add the appropriate selector even if it is a single element.

@gentleclockdivider First inlet of [pack] and many objects treats everything on the first inlet as a list which it unpacks and fans out to the other inlets in order, a symbol or float is just a list of one element in this case.

This is standard behavior for vanilla objects. [pak] is not vanilla and many external objects go against vanillas standard behavior.

@FFW try this, open ffw-test.pd and see if it expands on mouse over and shrinks when the mouse leaves. Restart pd before opening it just in case you have one of those weird things going on caused by a confused instance of pd. This should work,
Archive.zip
Edit: if it doesn't work, what version of pd are you running?

@FFW That is because you are not sending 0 to the third argument and then 1 or 2 as I do in mine. Sending 0 to that argument disables GOP then sending 1 or 2 reenables it which tells pd to redraw and the reason for all that extra stuff at the bottom of mine. Try something like this for your minimal test:

This should make it work, donecanvasdialog does the exact same thing as the canvas properties dialog does when you click "ok" or "apply," this is the exact message the tcl/tk frontend sends to the pd core so if your canvas properties dialog works than this should work.

Edit: Fixed some errors in the image, had 1 instead of $1.

@FFW said:

And [donecanvasdialog( is worse: all the guis remain visible as ghosts.

With your version or with the one I posted?

Your issue with the seq helpfile is just an error in the helpfile, possibly who ever made it used a custom font which can cause such issues for everyone who uses the default fonts.

@FFW This seems to work, but I can not quite see why yours does not work and I went through it removing every possible cause I could think of until I had pretty much this same patch, and it didn't work. Patch it together from scratch and it works, so probably something stupid and easy to miss in your patch and we are both missing the obvious. I added a third and fourth argument so you have shrunk width and hight and expanded width and height for args now and left some of the details for you to fill in.
ffw.pd

This seems pretty useful, easy way to make menus and dynamic interfaces, good idea to stick this in an abstraction, never dawned on me to do such a thing.

@FFW That one was my bad, I had not looked closely enough at your screenshot before responding. I am not seeing an obvious cause of your issue but a couple things jump out at me and could be troublesome. You are sending two coords messages for EVERY motion event on the parent canvas, put a [change -1] between the [expr] and the [sel 1] so it only does it once when the state actually needs to change. This will also make your expand and shrink methods work as expected, as of now if you send [expend( to the left inlet when the mouse is outside of the GOP it will immediately shrink back down the second the mouse moves, which I don't think is what you want?

Something like this would also be considerably more efficient than your [expr], as you have things now if you had 20 abstractions in the canvas which use this you do the [expr] 20 times for every motion event, that could really add up and cause problems, Did not test this, believe I have the logic right but if I don't it should demonstrate it. Obviously you would want to update x-max and y-max on every expand/shrink.

Adding in the [change] might fix things, pd might be getting confused by all those coords messages you are sending, not sure, no time to dig into it right now.

@FFW As far as I am aware there is no good way to determine how deeply nested in the patch an abstraction is. In the past when I have needed this I have used [canvasindex] since it produces no output if toplevel, something like this:

Possibly warrants a feature request on the pd github, results may happen quicker with an iemguts feature request but I am not sure if umlaeute has any interest in extending the features of iemguts but he is quick about dealing with bugs. Probably will not be a feature of vanilla anytime soon since the official way to deal with such things is [namecanvas] and named canvases which covers most use cases. With how things currently stand, numerical depth is more suited to the iemguts workflow than the pd workflow,

Edit: Not completly certain I understood you use case. Do you actually need to determine depth? Is the issue nested canvases? If depth is constant then [iemguts/sendcanvas] will solve your issue. I suspect my post was going the wrong direction and you don't need to worry about depth?

@FFW I do something like this:

Needs an [expr] with some if statements or a few [moses] and comparison/[expr if] to finish it up, but I think that shows the logic?

@Guest quick look at the pkgbuild, it creates its own XDG desktop file but does not delete the one which comes with the pd source, so you get two. Safe to delete one or the other and might be a bug to report to the package maintainer, no idea what the arch packaging guidelines are these days, been years since I used it.

@ben.wes [initbang] would not have to be in the subpatch, it would just replace the [loadbang] in the main patch. That idea was based on the guess that pd did initbangs right after object creation and then after all objects were created/initialized it would connect them and then do the loadbangs, but I just tested it and it seems it creates all objects, does the initbangs, connects them all and then does the loadbangs so we can not exploit creation order for this.

Regarding an installer patch, creating them can be automated easily enough with an abstraction so you don't have to do all that copying and pasting. Use an [openpanel] to select the patch and its abstractions you want to make an installer for, then drip the file list, have it open the file, send the selectall, copy, and close messages, create the suppatch, send paste and then close the subpatch. Repeat to the end of the file list. Have it finish off with it patching in the installer logic/abstraction and deleting itself with [iemguts/canvasdelete] so all that is left for you to do is a few informative comments. Suppose you could just read the main patch into a [text] and have it go through the objects and find the abstractions automatically, using a tcl plugin to search for the abstractions would probably be easiest but you could also use [iemguts/canvasindex] to find anything with the class of canvas and a binbuf which does not start with "pd " but tcl seems the better way to go here.

Edit: Actually, reading into a [text] and searching for abstractions does not need to be that complicated because we would not want to find abstractions from libraries, could do this mostly if not completely with [file], no tcl/externals.

@ben.wes if it were me I would also put main.pd into a subpatch and have a mypatch-installer.pd that installs all files and makes things explicit for the user. This also makes it so you can pop open savepanel and have it prompt the user for where to install and an easy way to do a fresh install, all those things people expect from an installer.

Edit: or is that what you are implying with the "everything" subpatch? Not quite clear on your example.

@willblackhurst I believe that would be working from pd's cwd which is not all that reliable and will change, possible savetofile always is relative to home dir but I would not expect that or rely on that. Best to always use full and absolute paths and use [file] to confirm all is well or you will eventually get bitten. Doubly so if you plan on sharing patches which exploit this.

@willblackhurst You can use the [savetofile( message to save a subpatch which you can then use as an abstraction:

But any existing instance of that abstraction in main.pd will fail to load since the subpatch will not be saved before the patch is loaded. You might be able to make that work with [iemguts/initbang] but not sure, if it does work you would have to pay attention to creation order, the subpatch would have to be created before any instance of the abstraction. You would also want to make use of [file] to check to see if the file already exists/guard against accidental overwriting of files, etc. There are few good uses of this and it should generally be avoided.

@tildebrow Like this? ccs.pd