Yeah, +1 for pdlua for me!
Here's a few more reasons I'd love to see this:
pdlua objects require vastly less boiler-plate code than C externals. Especially for signals and graphics, it takes care of all the hard parts and common pitfalls for you.
As a result, creating pdlua objects is much more beginner friendly, and experienced programmers are less likely to make mistakes. Not requiring compilation makes writing coded externals as accessible as abstractions are currently.
The biggest weakness for a project like pdlua is needing to be installed manually. This discourages people from directly uploading their Lua objects on Deken. Like porres said, ELSE now ships with pdlua just so that we can ship lua objects. It would be amazing if we could assume them to just work.
As you might know, Lua is very compact, it can be compiled by adding "onelua.c" to your sources, and it has no external dependencies. For ease of maintenance, it's as good at it gets. Lua is also fast for a scripting language. Seems like the perfect fit for pure-data.
If you want a sample of the API, here's the documentation for pdlua graphics: https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html#graphics
Tim
On 02/10/2024 06:12, Alexandre wrote:
Let me share Tim's thoughts he sent me via a chat about coding externals in lua, which I think are a perfect sell. Compared to C externals, lua externals:
- Encourages open-source, since the source code is the object
- Works on every OS, architecture, pd floatsize, multi-instance, all without needing recompilation
- You can easily modify objects if you want to
- GUIs are now much easier to write with Lua than with C
- Are guaranteed to keep working even if Pd's C API changes, or Pd changes GUI framework
- Are guaranteed to work across Pd forks, as long as they correctly implement the lua API
Em ter., 1 de out. de 2024 às 15:36, Alexandre porres@gmail.com escreveu:
Em seg., 30 de set. de 2024 às 16:59, Christof Ressi <info@christofressi.com> escreveu:Thanks to Antoine for mentioning pdlua! I will need to check it out. I have already seen people doing some very cool stuff with it. Maybe they already have the perfect solution :)I'm also looking at pdlua, which might want to become the official way to make graphical externs AND to add scripting in a fundamental way to Pd :)+1 for an official scripting language! :) (I love Lua, BTW.) And yes, it would make lots of sense to leverage the scripting language to implement custom UIs!+1k Yay, great to hear that! BTW, I remembered about this ticket we opened years ago inquiring about adding lua to Pd natively! https://github.com/pure-data/pure-data/issues/687 Now that Tim is doing great work for graphics, this would be even more awesome! And I wouldn't have to worry in shipping it in ELSE for some externals that already use it :) cheers
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WOQJIW3FBB7...
I know it's old but I think for lua in pd luaJit should be considered if adding a lua. Imo they took out a very powerful feature in setfenv after 5.1 anyways.
Luajit was still working with pdlua last I checked. Plus pd messages only use floats.
-Seb
On Wednesday, October 2, 2024 at 05:27:03 AM CDT, Timothy Schoen timschoen123@gmail.com wrote:
Yeah, +1 for pdlua for me!
Here's a few more reasons I'd love to see this:
* pdlua objects require vastly less boiler-plate code than C externals. Especially for signals and graphics, it takes care of all the hard parts and common pitfalls for you.
* As a result, creating pdlua objects is much more beginner friendly, and experienced programmers are less likely to make mistakes. Not requiring compilation makes writing coded externals as accessible as abstractions are currently.
* The biggest weakness for a project like pdlua is needing to be installed manually. This discourages people from directly uploading their Lua objects on Deken. Like porres said, ELSE now ships with pdlua just so that we can ship lua objects. It would be amazing if we could assume them to just work.
* As you might know, Lua is very compact, it can be compiled by adding "onelua.c" to your sources, and it has no external dependencies. For ease of maintenance, it's as good at it gets. Lua is also fast for a scripting language. Seems like the perfect fit for pure-data.
If you want a sample of the API, here's the documentation for pdlua graphics: https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html#graphics
Tim
On 02/10/2024 06:12, Alexandre wrote:
Let me share Tim's thoughts he sent me via a chat about coding externals in lua, which I think are a perfect sell. Compared to C externals, lua externals: * Encourages open-source, since the source code is the object * Works on every OS, architecture, pd floatsize, multi-instance, all without needing recompilation * You can easily modify objects if you want to * GUIs are now much easier to write with Lua than with C * Are guaranteed to keep working even if Pd's C API changes, or Pd changes GUI framework * Are guaranteed to work across Pd forks, as long as they correctly implement the lua API
Em ter., 1 de out. de 2024 às 15:36, Alexandre porres@gmail.com escreveu:
Em seg., 30 de set. de 2024 às 16:59, Christof Ressi info@christofressi.com escreveu:
> Thanks to Antoine for mentioning pdlua! I will need to check it out. I have already seen people doing some very cool stuff with it. Maybe they already have the perfect solution :) > > I'm also looking at pdlua, which might want to become the official way to make graphical externs AND to add scripting in a fundamental way to Pd :)
+1 for an official scripting language! :) (I love Lua, BTW.) And yes, it would make lots of sense to leverage the scripting language to implement custom UIs!
+1k
Yay, great to hear that! BTW, I remembered about this ticket we opened years ago inquiring about adding lua to Pd natively! https://github.com/pure-data/pure-data/issues/687
Now that Tim is doing great work for graphics, this would be even more awesome! And I wouldn't have to worry in shipping it in ELSE for some externals that already use it :)
cheers
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WOQJIW3FBB7...
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/GG7IF7MWRG...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
LuaJIT is awesome, but is it a good idea to run a JIT on the audio thread? Compiling code is certainly not realtime safe and I think we have no control over /when /individual functions are being compiled. So while LuaJIT would give better performance, I assume it would have a larger worst-case latency. One the other hand, LuaJIT also has a faster bytecode interpreter (written in hand-optimized assembly). We could allow people to select the JIT compiler or the bytecode interpreter as a runtime option.
Side note: LuaJIT also supports a subset of Lua 5.2.
On 02.10.2024 16:09, Sebastian Shader via Pd-list wrote:
I know it's old but I think for lua in pd luaJit should be considered if adding a lua. Imo they took out a very powerful feature in setfenv after 5.1 anyways.
Luajit was still working with pdlua last I checked. Plus pd messages only use floats.
-Seb
On Wednesday, October 2, 2024 at 05:27:03 AM CDT, Timothy Schoentimschoen123@gmail.com wrote:
Yeah, +1 for pdlua for me!
Here's a few more reasons I'd love to see this:
* pdlua objects require vastly less boiler-plate code than C externals. Especially for signals and graphics, it takes care of all the hard parts and common pitfalls for you.
* As a result, creating pdlua objects is much more beginner friendly, and experienced programmers are less likely to make mistakes. Not requiring compilation makes writing coded externals as accessible as abstractions are currently.
* The biggest weakness for a project like pdlua is needing to be installed manually. This discourages people from directly uploading their Lua objects on Deken. Like porres said, ELSE now ships with pdlua just so that we can ship lua objects. It would be amazing if we could assume them to just work.
* As you might know, Lua is very compact, it can be compiled by adding "onelua.c" to your sources, and it has no external dependencies. For ease of maintenance, it's as good at it gets. Lua is also fast for a scripting language. Seems like the perfect fit for pure-data.
If you want a sample of the API, here's the documentation for pdlua graphics:https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html#graphics
Tim
On 02/10/2024 06:12, Alexandre wrote:
Let me share Tim's thoughts he sent me via a chat about coding externals in lua, which I think are a perfect sell. Compared to C externals, lua externals:
* Encourages open-source, since the source code is the object
* Works on every OS, architecture, pd floatsize, multi-instance, all without needing recompilation
* You can easily modify objects if you want to
* GUIs are now much easier to write with Lua than with C
* Are guaranteed to keep working even if Pd's C API changes, or Pd changes GUI framework
* Are guaranteed to work across Pd forks, as long as they correctly implement the lua API
Em ter., 1 de out. de 2024 às 15:36, Alexandreporres@gmail.com escreveu:
Em seg., 30 de set. de 2024 às 16:59, Christof Ressiinfo@christofressi.com escreveu:
>
>> Thanks to Antoine for mentioning pdlua! I will need to check it out. I have already seen people doing some very cool stuff with it. Maybe they already have the perfect solution :) >> >> > I'm also looking at pdlua, which might want to become the official way to make graphical externs AND to add scripting in a fundamental way to Pd :) >+1 for an official scripting language! :) (I love Lua, BTW.) And yes, it would make lots of sense to leverage the scripting language to implement custom UIs!
+1k
Yay, great to hear that! BTW, I remembered about this ticket we opened years ago inquiring about adding lua to Pd natively!https://github.com/pure-data/pure-data/issues/687
Now that Tim is doing great work for graphics, this would be even more awesome! And I wouldn't have to worry in shipping it in ELSE for some externals that already use it :)
cheers
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WOQJIW3FBB7...
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/GG7IF7MWRG...
To unsubscribe send an email topd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/TJOTDRAY3L...
To unsubscribe send an email topd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.iem.at/
Currently, pdlua is not compatible with luaJIT, since it was updated to Lua 5.4 (and uses some of the new features internally). It's possible to port it back to luaJIT by taking out all the new Lua bits.
Both have some advantages and disadvantages. But for me, regular Lua would win (but only by a small amount). The reason is: it's architecturally simpler, more mainstream, more widely used/tested, and (in my estimation) more likely to be maintained for a very long time. luaJIT is very fast, so I'm not opposed to it either. Having any kind of scripting for objects available at all is the most important thing here 🙂
Tim
On 02/10/2024 16:09, Sebastian Shader via Pd-list wrote:
I know it's old but I think for lua in pd luaJit should be considered if adding a lua. Imo they took out a very powerful feature in setfenv after 5.1 anyways.
Luajit was still working with pdlua last I checked. Plus pd messages only use floats.
-Seb
On Wednesday, October 2, 2024 at 05:27:03 AM CDT, Timothy Schoen timschoen123@gmail.com wrote:
Yeah, +1 for pdlua for me!
Here's a few more reasons I'd love to see this:
* pdlua objects require vastly less boiler-plate code than C externals. Especially for signals and graphics, it takes care of all the hard parts and common pitfalls for you.
* As a result, creating pdlua objects is much more beginner friendly, and experienced programmers are less likely to make mistakes. Not requiring compilation makes writing coded externals as accessible as abstractions are currently.
* The biggest weakness for a project like pdlua is needing to be installed manually. This discourages people from directly uploading their Lua objects on Deken. Like porres said, ELSE now ships with pdlua just so that we can ship lua objects. It would be amazing if we could assume them to just work.
* As you might know, Lua is very compact, it can be compiled by adding "onelua.c" to your sources, and it has no external dependencies. For ease of maintenance, it's as good at it gets. Lua is also fast for a scripting language. Seems like the perfect fit for pure-data.
If you want a sample of the API, here's the documentation for pdlua graphics: https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html#graphics
Tim
On 02/10/2024 06:12, Alexandre wrote:
Let me share Tim's thoughts he sent me via a chat about coding externals in lua, which I think are a perfect sell. Compared to C externals, lua externals:
* Encourages open-source, since the source code is the object
* Works on every OS, architecture, pd floatsize, multi-instance, all without needing recompilation
* You can easily modify objects if you want to
* GUIs are now much easier to write with Lua than with C
* Are guaranteed to keep working even if Pd's C API changes, or Pd changes GUI framework
* Are guaranteed to work across Pd forks, as long as they correctly implement the lua API
Em ter., 1 de out. de 2024 às 15:36, Alexandre porres@gmail.com escreveu:
Em seg., 30 de set. de 2024 às 16:59, Christof Ressi info@christofressi.com escreveu:
>
>> Thanks to Antoine for mentioning pdlua! I will need to check it out. I have already seen people doing some very cool stuff with it. Maybe they already have the perfect solution :) >> >> > I'm also looking at pdlua, which might want to become the official way to make graphical externs AND to add scripting in a fundamental way to Pd :) >+1 for an official scripting language! :) (I love Lua, BTW.) And yes, it would make lots of sense to leverage the scripting language to implement custom UIs!
+1k
Yay, great to hear that! BTW, I remembered about this ticket we opened years ago inquiring about adding lua to Pd natively! https://github.com/pure-data/pure-data/issues/687
Now that Tim is doing great work for graphics, this would be even more awesome! And I wouldn't have to worry in shipping it in ELSE for some externals that already use it :)
cheers
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WOQJIW3FBB7...
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/GG7IF7MWRG...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/TJOTDRAY3L...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
On 02.10.2024 18:30, Timothy Schoen wrote:
Currently, pdlua is not compatible with luaJIT, since it was updated to Lua 5.4 (and uses some of the new features internally). It's possible to port it back to luaJIT by taking out all the new Lua bits.
Both have some advantages and disadvantages. But for me, regular Lua would win (but only by a small amount). The reason is: it's architecturally simpler, more mainstream, more widely used/tested, and (in my estimation) more likely to be maintained for a very long time. luaJIT is very fast, so I'm not opposed to it either. Having any kind of scripting for objects available at all is the most important thing here 🙂
If LuaJIT stopped working for whatever reason, we could still use vanilla Lua 5.1 - which will continue to work as long as we have C compilers :) Lua is a bit peculiar in that every minor version is really a different language. Once you pick a Lua version, you typically don't upgrade, unless there is some very compelling reason.
Personally, I'm using Lua 5.3 and I would also tend towards Lua 5.3 or 5.4. We just have to be aware that once we pick a version, we basically have to stick with it because of backwards compatibility.
Christof
Tim
On 02/10/2024 16:09, Sebastian Shader via Pd-list wrote:
I know it's old but I think for lua in pd luaJit should be considered if adding a lua. Imo they took out a very powerful feature in setfenv after 5.1 anyways.
Luajit was still working with pdlua last I checked. Plus pd messages only use floats.
-Seb
On Wednesday, October 2, 2024 at 05:27:03 AM CDT, Timothy Schoen timschoen123@gmail.com wrote:
Yeah, +1 for pdlua for me!
Here's a few more reasons I'd love to see this:
* pdlua objects require vastly less boiler-plate code than C externals. Especially for signals and graphics, it takes care of all the hard parts and common pitfalls for you.
* As a result, creating pdlua objects is much more beginner friendly, and experienced programmers are less likely to make mistakes. Not requiring compilation makes writing coded externals as accessible as abstractions are currently.
* The biggest weakness for a project like pdlua is needing to be installed manually. This discourages people from directly uploading their Lua objects on Deken. Like porres said, ELSE now ships with pdlua just so that we can ship lua objects. It would be amazing if we could assume them to just work.
* As you might know, Lua is very compact, it can be compiled by adding "onelua.c" to your sources, and it has no external dependencies. For ease of maintenance, it's as good at it gets. Lua is also fast for a scripting language. Seems like the perfect fit for pure-data.
If you want a sample of the API, here's the documentation for pdlua graphics: https://agraef.github.io/pd-lua/tutorial/pd-lua-intro.html#graphics
Tim
On 02/10/2024 06:12, Alexandre wrote:
Let me share Tim's thoughts he sent me via a chat about coding externals in lua, which I think are a perfect sell. Compared to C externals, lua externals: * Encourages open-source, since the source code is the object * Works on every OS, architecture, pd floatsize, multi-instance, all without needing recompilation * You can easily modify objects if you want to * GUIs are now much easier to write with Lua than with C * Are guaranteed to keep working even if Pd's C API changes, or Pd changes GUI framework * Are guaranteed to work across Pd forks, as long as they correctly implement the lua API
Em ter., 1 de out. de 2024 às 15:36, Alexandre porres@gmail.com escreveu:
Em seg., 30 de set. de 2024 às 16:59, Christof Ressi info@christofressi.com escreveu:
>>> Thanks to Antoine for mentioning pdlua! I will need to >>> check it out. I have already seen people doing some very cool >>> stuff with it. Maybe they already have the perfect solution :) >>> >>> >> I'm also looking at pdlua, which might want to become the >> official way to make graphical externs AND to add scripting in >> a fundamental way to Pd :) >> +1 for an official scripting language! :) (I love Lua, BTW.) And yes, it would make lots of sense to leverage the scripting language to implement custom UIs!
+1k
Yay, great to hear that! BTW, I remembered about this ticket we opened years ago inquiring about adding lua to Pd natively! https://github.com/pure-data/pure-data/issues/687
Now that Tim is doing great work for graphics, this would be even more awesome! And I wouldn't have to worry in shipping it in ELSE for some externals that already use it :)
cheers
--- pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/WOQJIW3FBB7...
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/GG7IF7MWRG...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/TJOTDRAY3L...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/F6CWKKSQHE...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
-
Christof Ressi -
Sebastian Shader -
Timothy Schoen