deken update?

[ben-wes]

this is not an actual issue and also certainly not the right place to address it. :)

anyway ... i was just about to install the newest pdlua version and took the obvious way through deken. but i saw that it's not available there yet. any plans for an upload to deken? otherwise, i'd be glad to support and do it if you agree with the idea?

(obviously, i got it from here then - but i'm sure there are a few Pd users that would appreciate the simple option)

[agraef]

Ben, that would be much appreciated! I already have way too many packages to maintain, and I don't know much about Deken packaging, so please by all means just go ahead.

[ben-wes]

voilà: https://deken.puredata.info/library/pdlua/0.12.4

i'll also make an announcement on the pd list with a little change log, thanking tim and you!

[ben-wes]

done for this 0.12.4. will gladly do it again for future versions. if there'll be a lot more releases, we can also add the deken upload to the github actions - no need right now though. :)

[agraef]

voilà: https://deken.puredata.info/library/pdlua/0.12.4

Awesome! Just installed it in vanilla 0.55.0, works like a charm. Thanks a bunch!

we can also add the deken upload to the github actions

That's a very good idea. If it's not too much work, let's just go ahead with this right away. The next update is just a single commit away. ;-) Please send me a PR when you find the time.

Tim and I have actually been tossing around some ideas on how to optimize the graphics rendering in https://github.com/agraef/pd-lua/pull/45#issuecomment-2276655763. And I started thinking about how to add svg graphics. At least on Purr Data that shouldn't be much work, as its canvas is just an svg element in a html5 document body anyway. Would be nice to have that possibility so that you could easily include sprites in your graphics, like we have in Purr Data's svg data structures (see the walking cat in Purr's about dialog for an example).

BTW, Tim and I are both going to next year's Linux Audio Conference at Lyon (yes, LAC is finally back, hurray!). By any chance, do you plan to go there as well? Then the three of us could maybe do a paper together? I need to update the pd-lua tutorial with a section on signals and graphics anyway, so I could just reuse that material to write the bulk of the paper. Tim is already joining me on this, I would be happy to have you on that paper as well. LAC is always a lot of fun, the food and wine in Lyon is plentiful and good, and many old friends will be there. :))

[agraef]

BTW, is there a way to have vanilla's help browser add the directories in ~/Documents/Pd/externals (or at least the directories on the help path, -helppath) to the help browser (Ctrl+B)? In Purr Data the help browser will (optionally) cover whatever help paths you have set up, but vanilla's help browser seems much more limited.

[timothyschoen]

For SVG on other pd flavours, we could use nanosvg: https://github.com/memononen/nanosvg

It converts any svg file into bezier curves, which we can already render with pdlua. Not sure about the performance there though!

I've thought about optimisation. The simplest thing I could imagine, is being able to render multiple layers like this:

function MyObj:paint(g)
  -- paint base layer
end

function MyObj:paint_layer_2(g)
  -- paint layer on top of that
end

repaint() -- repaint all
repaint(1) -- repaint only base layer
repaint(2) -- repaint only second layer

That way, you can put things that need to be updated a lot in a layer that is repainted separately. Compared to my previous concept with subcomponents, this is easier to implement, and it makes it easier to deal with cases where your updating layer is in between two other layers. And it means that we can still force a repaint if needed, which would be tricky with my previous concept.

[ben-wes]

is there a way to have vanilla's help browser add the directories in ~/Documents/Pd/externals

it looks to me like single paths that i have added through the settings make it to the help browser:

... these are my custom paths in the settings:

[ben-wes]

I would be happy to have you on that paper as well. LAC is always a lot of fun, the food and wine in Lyon is plentiful and good, and many old friends will be there. :))

responding via dm to this! :)

[ben-wes]

Please send me a PR when you find the time.

i'm not making a PR yet here since i consider my workflow knowledge quite limited and there are certainly more elegant ways! but if you want to check: these should (hopefully) be valid builds for 32-bit and 64-bit Pd now that are getting merged per OS for the upload to deken. https://github.com/ben-wes/pd-lua/actions/runs/10477360872

changes: https://github.com/agraef/pd-lua/compare/master...ben-wes:pd-lua:build-tests

the workflow is printing a lot of summary of deken zips' content per OS, which i found useful for my simplex noise external - but here, i'm not sure. :)

when pushing a tag, this would automatically make a deken release now, unless the tag contains "test". maybe this is too open? and of course, it can only upload to deken if the action secrets DEKEN_USERNAME and DEKEN_PASSWORD are defined for the repository.

the builds are currently only tested for macOS arm64 with pd32 and pd64. so amd64 for both floatsizes on all OS's still needs testing.

[ben-wes]

update: also tested on win11 now with pd32 and pd64. so currently untested are:

• macos on amd64 with pd32 and pd64 (i'm confident that these work since these are universal builds)
• linux with pd32 and pd64

... pd64 releases are available here: https://puredata.info/downloads/pure-data/releases/0.55-0-pd64

[agraef]

it looks to me like single paths that i have added through the settings make it to the help browser

Thanks! I should've known that (I'm pretty sure that I've done it before that way), but I tend to forget things these days. Poor old brain, put one chunk of data in, another one falls out. ;-)

i'm not making a PR yet

Fair enough. As long as you keep maintaining it, I'm happy with you doing it on your fork.

since i consider my workflow knowledge quite limited

You do much better than myself. :)

[ben-wes]

Poor old brain, put one chunk of data in, another one falls out. ;-)

ring buffers are not a bad thing. :)

i'm not making a PR yet

Fair enough. As long as you keep maintaining it, I'm happy with you doing it on your fork.

ah - that was probably a bit of a misunderstanding! of course, i can just keep my fork in sync and do the releases. but if the workflow looks alright to and if you have credentials for the deken uploads (for puredata.info), then i'm totally fine with creating a PR ... any future version that you tag will then automatically be on deken (if you added the repository secrets DEKEN_USERNAME and DEKEN_PASSWORD).

i just tagged 0.12.4 on my fork and the result on deken looks good: https://deken.puredata.info/library/pdlua/0.12.4

so i'll now create a PR and leave the decision to you. i'm fine with either option!

[agraef]

For SVG on other pd flavours, we could use nanosvg

Nice! I also like the layer idea, sounds like a clean approach to me. Tim, I can do the purr-data implementation once you've implemented the vanilla interface, for both the layer and the svg APIs. Ben, you can then maybe cook up one of your cool examples? I take it that we'll all be at LAC @ Lyon next year, then we can maybe discuss this further at the conference.

[agraef]

so i'll now create a PR and leave the decision to you. i'm fine with either option!

Merged, all done and dusted, thanks a bunch! I'll just have to check whether all the automatic uploads still work over here, especially the Deken upload, next time I tag a release. I may then have to get back to you if anything goes wrong. :)