To Pd dev -
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March. As usual I plan to merge in "devel" and "Documentation" - in fact I should do a first merge rather soon, assuming things are in a good state for merging.
I'm planning to add a couple of features: 1. message to Pd to toggle between GUI and no-GUI -- perhaps with a way to reset the GUI startup command -- so that if you have a headless installation that's doing something funny you can pop it open and look; and 2. improvements to the "pointer" object to make it easier to get around data structures, and possibly a menu extension for dragging new "data" onto the screen; 3. an optional pop-up display showing (x,y) coordinates of object or data knob being dragged.
Incidentally: I just noticed that the IEM slider object (and proabbly other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm..
cheers
Miller
Hi Miller,
good to hear from you!
Just a question: since you plan to add new features, this would be Pd 0.55 - and not Pd 0.54.2 - right?
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March.
That's a pretty narrow merge window, given that Easter holidays already start on March 23, which some of us want to spend with our families. I really appreciate the announcement, but it would be great if it could come a bit more in advance (i.e. more than 2 weeks before feature freeze). We all have jobs and/or families. I love to contribute to Pd, but I really need to plan ahead of time.
In general, instead of a very dense 2-week merge window twice a year, it would great to merge PRs on a mere regular basis. Not only would it cause less stress, it would also give us more time to find bugs before the actual release. That's just my personal opinion, of course.
---
A few things from my side:
1. Please consider my scheduler improvements: https://github.com/pure-data/pure-data/pull/1756
I have been using this for 1 1/2 years now, both in my daily patching and in big concerts (including an opera production!), and I can't live without it anymore. It would be nice if other people could enjoy these improvements as well. Also, I wouldn't have to hand out custom Pd versions to my performers anymore :)
---
2. There are quite a few missing multichannel features!
Here are my multichannel PRs:
* MC support for [print~], [snapshot~] and [sig~]: https://github.com/pure-data/pure-data/pull/1978
* MC support for [readsf~] and [writesf~]: https://github.com/pure-data/pure-data/pull/2052
* MC support for [delwrite~], [delread~] and [delread4~]: https://github.com/pure-data/pure-data/pull/2049
* allow to change the number of tables/channels in table DSP objects: https://github.com/pure-data/pure-data/pull/2058
* signal comparison operators (finally!) with multichannel support: https://github.com/pure-data/pure-data/pull/2054
The [snake~] object is also missing a few crucial features, most importantly:
* query the number of channels in a MC signal, e.g. [snake~ count]
* combine several MC signals into a single MC signal, e.g. [snake~ join], or extend [snake~ in to accept multichannel signals
* split a MC signal into several MC signals resp. get a subset of channels, e.g. [snake~ split] resp. [snake~ get]
* sum a MC signal, e.g. [snake~ sum]
People are already implementing these as externals, but these features seem so basic that they really should be part of Pd vanilla IMO.
For reference, here's the discussion: https://github.com/pure-data/pure-data/issues/1996
---
A few other things I really want to see eventually (not necessarily for this release):
* more clone improvements: https://github.com/pure-data/pure-data/pull/2053
* "goprect" method: https://github.com/pure-data/pure-data/pull/627. Solves a real issue and lying around for 5 years now.
* namespace constructors for all external objects: https://github.com/pure-data/pure-data/pull/630. Solves a real issue and lying around for 5 years.
Cheers,
Christof
PS: here is a full list of my open PRs, in case anyone is interested: https://github.com/pure-data/pure-data/pulls/Spacechild1?page=1&q=is%3Ao...
On 12.03.2024 08:47, Miller Puckette wrote:
To Pd dev -
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March. As usual I plan to merge in "devel" and "Documentation" - in fact I should do a first merge rather soon, assuming things are in a good state for merging.
I'm planning to add a couple of features: 1. message to Pd to toggle between GUI and no-GUI -- perhaps with a way to reset the GUI startup command -- so that if you have a headless installation that's doing something funny you can pop it open and look; and 2. improvements to the "pointer" object to make it easier to get around data structures, and possibly a menu extension for dragging new "data" onto the screen; 3. an optional pop-up display showing (x,y) coordinates of object or data knob being dragged.
Incidentally: I just noticed that the IEM slider object (and proabbly other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm..
cheers
Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Effectively, what I'm hoping to do is start merging soon, assuming nobody objects, but to stop admitting new features after a couple of weeks so that we can have most of April to look at what we've got and fix bugs (but not try to add stuff). so the "freeze" period would be as long as people need to feel confident.
OTOH if you want to keep adding features during April while we're waiting for bug reports, we can start a "0.56" branch and merge it into master once 0.55 is out. (and yes, I'm imagining numbering it 0.55). But I can be flexible on all of this.
I'll look at the PRs suggested below... they all sound worthwhile.
cheers Miller
On 3/12/24 11:49, Christof Ressi wrote:
Hi Miller,
good to hear from you!
Just a question: since you plan to add new features, this would be Pd 0.55 - and not Pd 0.54.2 - right?
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March.
That's a pretty narrow merge window, given that Easter holidays already start on March 23, which some of us want to spend with our families. I really appreciate the announcement, but it would be great if it could come a bit more in advance (i.e. more than 2 weeks before feature freeze). We all have jobs and/or families. I love to contribute to Pd, but I really need to plan ahead of time.
In general, instead of a very dense 2-week merge window twice a year, it would great to merge PRs on a mere regular basis. Not only would it cause less stress, it would also give us more time to find bugs before the actual release. That's just my personal opinion, of course.
A few things from my side:
- Please consider my scheduler improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1756...
I have been using this for 1 1/2 years now, both in my daily patching and in big concerts (including an opera production!), and I can't live without it anymore. It would be nice if other people could enjoy these improvements as well. Also, I wouldn't have to hand out custom Pd versions to my performers anymore :)
- There are quite a few missing multichannel features!
Here are my multichannel PRs:
- MC support for [print~], [snapshot~] and [sig~]:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1978...
- MC support for [readsf~] and [writesf~]:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2052...
- MC support for [delwrite~], [delread~] and [delread4~]:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2049...
- allow to change the number of tables/channels in table DSP objects:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2058...
- signal comparison operators (finally!) with multichannel support:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2054...
The [snake~] object is also missing a few crucial features, most importantly:
query the number of channels in a MC signal, e.g. [snake~ count]
combine several MC signals into a single MC signal, e.g. [snake~
join], or extend [snake~ in to accept multichannel signals
- split a MC signal into several MC signals resp. get a subset of
channels, e.g. [snake~ split] resp. [snake~ get]
- sum a MC signal, e.g. [snake~ sum]
People are already implementing these as externals, but these features seem so basic that they really should be part of Pd vanilla IMO.
For reference, here's the discussion: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/19...
A few other things I really want to see eventually (not necessarily for this release):
- more clone improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2053...
- "goprect" method:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/627_... . Solves a real issue and lying around for 5 years now.
- namespace constructors for all external objects:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/630_... . Solves a real issue and lying around for 5 years.
Cheers,
Christof
PS: here is a full list of my open PRs, in case anyone is interested: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pulls/Spa...
On 12.03.2024 08:47, Miller Puckette wrote:
To Pd dev -
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March. As usual I plan to merge in "devel" and "Documentation" - in fact I should do a first merge rather soon, assuming things are in a good state for merging.
I'm planning to add a couple of features: 1. message to Pd to toggle between GUI and no-GUI -- perhaps with a way to reset the GUI startup command -- so that if you have a headless installation that's doing something funny you can pop it open and look; and 2. improvements to the "pointer" object to make it easier to get around data structures, and possibly a menu extension for dragging new "data" onto the screen; 3. an optional pop-up display showing (x,y) coordinates of object or data knob being dragged.
Incidentally: I just noticed that the IEM slider object (and proabbly other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm..
cheers
Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Hi Miller,
thanks a lot! Sounds way less scary :)
Cheers,
Christof
On 12.03.2024 12:06, Miller Puckette wrote:
Effectively, what I'm hoping to do is start merging soon, assuming nobody objects, but to stop admitting new features after a couple of weeks so that we can have most of April to look at what we've got and fix bugs (but not try to add stuff). so the "freeze" period would be as long as people need to feel confident.
OTOH if you want to keep adding features during April while we're waiting for bug reports, we can start a "0.56" branch and merge it into master once 0.55 is out. (and yes, I'm imagining numbering it 0.55). But I can be flexible on all of this.
I'll look at the PRs suggested below... they all sound worthwhile.
cheers Miller
On 3/12/24 11:49, Christof Ressi wrote:
Hi Miller,
good to hear from you!
Just a question: since you plan to add new features, this would be Pd 0.55 - and not Pd 0.54.2 - right?
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March.
That's a pretty narrow merge window, given that Easter holidays already start on March 23, which some of us want to spend with our families. I really appreciate the announcement, but it would be great if it could come a bit more in advance (i.e. more than 2 weeks before feature freeze). We all have jobs and/or families. I love to contribute to Pd, but I really need to plan ahead of time.
In general, instead of a very dense 2-week merge window twice a year, it would great to merge PRs on a mere regular basis. Not only would it cause less stress, it would also give us more time to find bugs before the actual release. That's just my personal opinion, of course.
A few things from my side:
- Please consider my scheduler improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1756...
I have been using this for 1 1/2 years now, both in my daily patching and in big concerts (including an opera production!), and I can't live without it anymore. It would be nice if other people could enjoy these improvements as well. Also, I wouldn't have to hand out custom Pd versions to my performers anymore :)
- There are quite a few missing multichannel features!
Here are my multichannel PRs:
- MC support for [print~], [snapshot~] and [sig~]:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1978...
- MC support for [readsf~] and [writesf~]:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2052...
- MC support for [delwrite~], [delread~] and [delread4~]:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2049...
- allow to change the number of tables/channels in table DSP objects:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2058...
- signal comparison operators (finally!) with multichannel support:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2054...
The [snake~] object is also missing a few crucial features, most importantly:
query the number of channels in a MC signal, e.g. [snake~ count]
combine several MC signals into a single MC signal, e.g. [snake~
join], or extend [snake~ in to accept multichannel signals
- split a MC signal into several MC signals resp. get a subset of
channels, e.g. [snake~ split] resp. [snake~ get]
- sum a MC signal, e.g. [snake~ sum]
People are already implementing these as externals, but these features seem so basic that they really should be part of Pd vanilla IMO.
For reference, here's the discussion: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/19...
A few other things I really want to see eventually (not necessarily for this release):
- more clone improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2053...
- "goprect" method:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/627_... . Solves a real issue and lying around for 5 years now.
- namespace constructors for all external objects:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/630_... . Solves a real issue and lying around for 5 years.
Cheers,
Christof
PS: here is a full list of my open PRs, in case anyone is interested: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pulls/Spa...
On 12.03.2024 08:47, Miller Puckette wrote:
To Pd dev -
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March. As usual I plan to merge in "devel" and "Documentation" - in fact I should do a first merge rather soon, assuming things are in a good state for merging.
I'm planning to add a couple of features: 1. message to Pd to toggle between GUI and no-GUI -- perhaps with a way to reset the GUI startup command -- so that if you have a headless installation that's doing something funny you can pop it open and look; and 2. improvements to the "pointer" object to make it easier to get around data structures, and possibly a menu extension for dragging new "data" onto the screen; 3. an optional pop-up display showing (x,y) coordinates of object or data knob being dragged.
Incidentally: I just noticed that the IEM slider object (and proabbly other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm..
cheers
Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I replied without seeing other messages, sorry, in a rush here :)
Em ter., 12 de mar. de 2024 às 10:20, Alexandre Torres Porres < porres@gmail.com> escreveu:
Some PRs for that
https://github.com/pure-data/pure-data/pull/2059 https://github.com/pure-data/pure-data/pull/1978 https://github.com/pure-data/pure-data/pull/2049 https://github.com/pure-data/pure-data/pull/2052 https://github.com/pure-data/pure-data/pull/2110
so, besides multichannel stuff from christof in the middle, last one is adding MC secondary signals to clip~ and the 1st is to draw a thicker MC connection line
In general, instead of a very dense 2-week merge window twice a year, it would great to merge PRs on a mere regular basis. Not only would it cause less stress, it would also give us more time to find bugs before the actual release. That's just my personal opinion, of course.
+10000 :)
may I ask if you're finally retired from classes at UCSD by the way Miller ;)
cheers
A few things from my side:
- Please consider my scheduler improvements:
https://github.com/pure-data/pure-data/pull/1756
I have been using this for 1 1/2 years now, both in my daily patching and in big concerts (including an opera production!), and I can't live without it anymore. It would be nice if other people could enjoy these improvements as well. Also, I wouldn't have to hand out custom Pd versions to my performers anymore :)
- There are quite a few missing multichannel features!
Here are my multichannel PRs:
- MC support for [print~], [snapshot~] and [sig~]:
https://github.com/pure-data/pure-data/pull/1978
- MC support for [readsf~] and [writesf~]:
https://github.com/pure-data/pure-data/pull/2052
- MC support for [delwrite~], [delread~] and [delread4~]:
https://github.com/pure-data/pure-data/pull/2049
- allow to change the number of tables/channels in table DSP objects:
https://github.com/pure-data/pure-data/pull/2058
- signal comparison operators (finally!) with multichannel support:
https://github.com/pure-data/pure-data/pull/2054
The [snake~] object is also missing a few crucial features, most importantly:
query the number of channels in a MC signal, e.g. [snake~ count]
combine several MC signals into a single MC signal, e.g. [snake~
join], or extend [snake~ in to accept multichannel signals
- split a MC signal into several MC signals resp. get a subset of
channels, e.g. [snake~ split] resp. [snake~ get]
- sum a MC signal, e.g. [snake~ sum]
People are already implementing these as externals, but these features seem so basic that they really should be part of Pd vanilla IMO.
For reference, here's the discussion: https://github.com/pure-data/pure-data/issues/1996
A few other things I really want to see eventually (not necessarily for this release):
- more clone improvements:
https://github.com/pure-data/pure-data/pull/2053
- "goprect" method: https://github.com/pure-data/pure-data/pull/627.
Solves a real issue and lying around for 5 years now.
- namespace constructors for all external objects:
https://github.com/pure-data/pure-data/pull/630. Solves a real issue and lying around for 5 years.
Cheers,
Christof
PS: here is a full list of my open PRs, in case anyone is interested:
https://github.com/pure-data/pure-data/pulls/Spacechild1?page=1&q=is%3Ao...
On 12.03.2024 08:47, Miller Puckette wrote:
To Pd dev -
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March. As usual I plan to merge in "devel" and "Documentation" - in fact I should do a first merge rather soon, assuming things are in a good state for merging.
I'm planning to add a couple of features: 1. message to Pd to toggle between GUI and no-GUI -- perhaps with a way to reset the GUI startup command -- so that if you have a headless installation that's doing something funny you can pop it open and look; and 2. improvements to the "pointer" object to make it easier to get around data structures, and possibly a menu extension for dragging new "data" onto the screen; 3. an optional pop-up display showing (x,y) coordinates of object or data knob being dragged.
Incidentally: I just noticed that the IEM slider object (and proabbly other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm..
cheers
Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
@miller:
I just noticed that the IEM slider object spits out a number when clicked upon
This has always been the case as far as i know (and I've just tested on 0.43.0 and it was already true). I don't think this should change...
Le mar. 12 mars 2024 à 14:34, Alexandre Torres Porres porres@gmail.com a écrit :
I replied without seeing other messages, sorry, in a rush here :)
Em ter., 12 de mar. de 2024 às 10:20, Alexandre Torres Porres < porres@gmail.com> escreveu:
Some PRs for that
https://github.com/pure-data/pure-data/pull/2059 https://github.com/pure-data/pure-data/pull/1978 https://github.com/pure-data/pure-data/pull/2049 https://github.com/pure-data/pure-data/pull/2052 https://github.com/pure-data/pure-data/pull/2110
so, besides multichannel stuff from christof in the middle, last one is adding MC secondary signals to clip~ and the 1st is to draw a thicker MC connection line
In general, instead of a very dense 2-week merge window twice a year, it would great to merge PRs on a mere regular basis. Not only would it cause less stress, it would also give us more time to find bugs before the actual release. That's just my personal opinion, of course.
+10000 :)
may I ask if you're finally retired from classes at UCSD by the way Miller ;)
cheers
A few things from my side:
- Please consider my scheduler improvements:
https://github.com/pure-data/pure-data/pull/1756
I have been using this for 1 1/2 years now, both in my daily patching and in big concerts (including an opera production!), and I can't live without it anymore. It would be nice if other people could enjoy these improvements as well. Also, I wouldn't have to hand out custom Pd versions to my performers anymore :)
- There are quite a few missing multichannel features!
Here are my multichannel PRs:
- MC support for [print~], [snapshot~] and [sig~]:
https://github.com/pure-data/pure-data/pull/1978
- MC support for [readsf~] and [writesf~]:
https://github.com/pure-data/pure-data/pull/2052
- MC support for [delwrite~], [delread~] and [delread4~]:
https://github.com/pure-data/pure-data/pull/2049
- allow to change the number of tables/channels in table DSP objects:
https://github.com/pure-data/pure-data/pull/2058
- signal comparison operators (finally!) with multichannel support:
https://github.com/pure-data/pure-data/pull/2054
The [snake~] object is also missing a few crucial features, most importantly:
query the number of channels in a MC signal, e.g. [snake~ count]
combine several MC signals into a single MC signal, e.g. [snake~
join], or extend [snake~ in to accept multichannel signals
- split a MC signal into several MC signals resp. get a subset of
channels, e.g. [snake~ split] resp. [snake~ get]
- sum a MC signal, e.g. [snake~ sum]
People are already implementing these as externals, but these features seem so basic that they really should be part of Pd vanilla IMO.
For reference, here's the discussion: https://github.com/pure-data/pure-data/issues/1996
A few other things I really want to see eventually (not necessarily for this release):
- more clone improvements:
https://github.com/pure-data/pure-data/pull/2053
- "goprect" method: https://github.com/pure-data/pure-data/pull/627.
Solves a real issue and lying around for 5 years now.
- namespace constructors for all external objects:
https://github.com/pure-data/pure-data/pull/630. Solves a real issue and lying around for 5 years.
Cheers,
Christof
PS: here is a full list of my open PRs, in case anyone is interested:
https://github.com/pure-data/pure-data/pulls/Spacechild1?page=1&q=is%3Ao...
On 12.03.2024 08:47, Miller Puckette wrote:
To Pd dev -
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March. As usual I plan to merge in "devel" and "Documentation" - in fact I should do a first merge rather soon, assuming things are in a good state for
merging.
I'm planning to add a couple of features: 1. message to Pd to toggle between GUI and no-GUI -- perhaps with a way to reset the GUI startup command -- so that if you have a headless installation that's doing something funny you can pop it open and look; and 2. improvements to the "pointer" object to make it easier to get around data structures, and possibly a menu extension for dragging new "data" onto the screen; 3. an optional pop-up display showing (x,y) coordinates of object or data knob being dragged.
Incidentally: I just noticed that the IEM slider object (and proabbly other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm..
cheers
Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
hi,
excited to hear about an upcoming Pd0.55!
This has always been the case as far as i know (and I've just tested on 0.43.0 and it was already true). I don't think this should change...
+1 ... and just wanted to add to this: it might not be the obvious behavior for steady-on-click sliders (although i certainly just clicked on sliders in the past to set values) - but imho, it's expected for jump-on-click mode and it seems right if they behave consistently there.
cheers, ben
Am Di., 12. März 2024 um 15:05 Uhr schrieb Antoine Rousseau antoine@metalu.net:
@miller:
I just noticed that the IEM slider object spits out a number when clicked upon
This has always been the case as far as i know (and I've just tested on 0.43.0 and it was already true). I don't think this should change...
Le mar. 12 mars 2024 à 14:34, Alexandre Torres Porres porres@gmail.com a écrit :
I replied without seeing other messages, sorry, in a rush here :)
Em ter., 12 de mar. de 2024 às 10:20, Alexandre Torres Porres porres@gmail.com escreveu:
Some PRs for that
https://github.com/pure-data/pure-data/pull/2059 https://github.com/pure-data/pure-data/pull/1978 https://github.com/pure-data/pure-data/pull/2049 https://github.com/pure-data/pure-data/pull/2052 https://github.com/pure-data/pure-data/pull/2110
so, besides multichannel stuff from christof in the middle, last one is adding MC secondary signals to clip~ and the 1st is to draw a thicker MC connection line
In general, instead of a very dense 2-week merge window twice a year, it would great to merge PRs on a mere regular basis. Not only would it cause less stress, it would also give us more time to find bugs before the actual release. That's just my personal opinion, of course.
+10000 :)
may I ask if you're finally retired from classes at UCSD by the way Miller ;)
cheers
A few things from my side:
- Please consider my scheduler improvements:
https://github.com/pure-data/pure-data/pull/1756
I have been using this for 1 1/2 years now, both in my daily patching and in big concerts (including an opera production!), and I can't live without it anymore. It would be nice if other people could enjoy these improvements as well. Also, I wouldn't have to hand out custom Pd versions to my performers anymore :)
- There are quite a few missing multichannel features!
Here are my multichannel PRs:
- MC support for [print~], [snapshot~] and [sig~]:
https://github.com/pure-data/pure-data/pull/1978
- MC support for [readsf~] and [writesf~]:
https://github.com/pure-data/pure-data/pull/2052
- MC support for [delwrite~], [delread~] and [delread4~]:
https://github.com/pure-data/pure-data/pull/2049
- allow to change the number of tables/channels in table DSP objects:
https://github.com/pure-data/pure-data/pull/2058
- signal comparison operators (finally!) with multichannel support:
https://github.com/pure-data/pure-data/pull/2054
The [snake~] object is also missing a few crucial features, most importantly:
query the number of channels in a MC signal, e.g. [snake~ count]
combine several MC signals into a single MC signal, e.g. [snake~
join], or extend [snake~ in to accept multichannel signals
- split a MC signal into several MC signals resp. get a subset of
channels, e.g. [snake~ split] resp. [snake~ get]
- sum a MC signal, e.g. [snake~ sum]
People are already implementing these as externals, but these features seem so basic that they really should be part of Pd vanilla IMO.
For reference, here's the discussion: https://github.com/pure-data/pure-data/issues/1996
A few other things I really want to see eventually (not necessarily for this release):
more clone improvements: https://github.com/pure-data/pure-data/pull/2053
"goprect" method: https://github.com/pure-data/pure-data/pull/627.
Solves a real issue and lying around for 5 years now.
- namespace constructors for all external objects:
https://github.com/pure-data/pure-data/pull/630. Solves a real issue and lying around for 5 years.
Cheers,
Christof
PS: here is a full list of my open PRs, in case anyone is interested: https://github.com/pure-data/pure-data/pulls/Spacechild1?page=1&q=is%3Ao...
On 12.03.2024 08:47, Miller Puckette wrote:
To Pd dev -
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March. As usual I plan to merge in "devel" and "Documentation" - in fact I should do a first merge rather soon, assuming things are in a good state for merging.
I'm planning to add a couple of features: 1. message to Pd to toggle between GUI and no-GUI -- perhaps with a way to reset the GUI startup command -- so that if you have a headless installation that's doing something funny you can pop it open and look; and 2. improvements to the "pointer" object to make it easier to get around data structures, and possibly a menu extension for dragging new "data" onto the screen; 3. an optional pop-up display showing (x,y) coordinates of object or data knob being dragged.
Incidentally: I just noticed that the IEM slider object (and proabbly other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm..
cheers
Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Tue, 2024-03-12 at 11:49 +0100, Christof Ressi wrote:
- Please consider my scheduler improvements:
https://github.com/pure-data/pure-data/pull/1756
I have been using this for 1 1/2 years now, both in my daily patching and in big concerts (including an opera production!), and I can't live without it anymore. It would be nice if other people could enjoy these improvements as well. Also, I wouldn't have to hand out custom Pd versions to my performers anymore :)
+1
I've been using it constantly for the past year and I consider it a major improvement. My experience is based on Linux (mostly) and to some degree on macOS. From what I gathered, Christof has been using it extensively on Windows. I think it's ripe for inclusion.
Roman
hi, so it's 0.55 season, good news! I'll focus on that now ;)
I wanna stress and suggest one of the immediate goals must be improving multichannel stuff, there are some objects that still miss it and it'd be nice if a multichannel connection would be visibly distinct.
Some PRs for that
https://github.com/pure-data/pure-data/pull/2059 https://github.com/pure-data/pure-data/pull/1978 https://github.com/pure-data/pure-data/pull/2049 https://github.com/pure-data/pure-data/pull/2052 https://github.com/pure-data/pure-data/pull/2110
cheers
Em ter., 12 de mar. de 2024 às 04:48, Miller Puckette < mpuckette@cloud.ucsd.edu> escreveu:
To Pd dev -
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March. As usual I plan to merge in "devel" and "Documentation" - in fact I should do a first merge rather soon, assuming things are in a good state for merging.
I'm planning to add a couple of features: 1. message to Pd to toggle between GUI and no-GUI -- perhaps with a way to reset the GUI startup command -- so that if you have a headless installation that's doing something funny you can pop it open and look; and 2. improvements to the "pointer" object to make it easier to get around data structures, and possibly a menu extension for dragging new "data" onto the screen; 3. an optional pop-up display showing (x,y) coordinates of object or data knob being dragged.
Incidentally: I just noticed that the IEM slider object (and proabbly other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm..
cheers
Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Tue, 12 Mar 2024 at 04:48 Miller Puckette mpuckette@cloud.ucsd.edu wrote:
possibly a menu extension for dragging new "data" onto the screen;
Not sure what you mean, can you elaborate? I have this PR for adding objects, is it something like this?
https://github.com/pure-data/pure-data/issues/1917
Incidentally: I just noticed that the IEM slider object (and proabbly
other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm..
This is surely known
cheers
Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On Tue, 2024-03-12 at 08:47 +0100, Miller Puckette wrote:
Incidentally: I just noticed that the IEM slider object (and proabbly other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm..
Given Pd's limited set of GUI widgets I'm (ab)using the existing widgets for all kinds of stuff using their exact behavior. I'm sure I'm not the only one. One idiom I've used thousands of times is using sliders as bang buttons with adjustable size:
[hslider ] | [sel]X[t a] |
This works exactly because if you click it, it repeats the last value, thus giving a bang. However, it outputs nothing when dragging.
Roman
Em ter., 12 de mar. de 2024 às 04:48, Miller Puckette < mpuckette@cloud.ucsd.edu> escreveu:
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March. As usual I plan to merge in "devel" and "Documentation" - in fact I should do a first merge rather soon, assuming things are in a good state for merging.
Just did two last updates for the Documentation updates and it's ready to go, nothing on the horizon for me now but I know I'll work on more stuff as new things are included. Me, Lucarda and Ben are now working on a manual update to include detailed functionality of intelligent patching but it'll take a few weeks I guess, and it'll not be included in the main doc updates in the meantime.
cheers
Miller,
Could I also have your feelings about these 2 PR:
- https://github.com/pure-data/pure-data/pull/1659: modern canvas zoom and scroll - https://github.com/pure-data/pure-data/pull/1738: round knob GUI
thanks!
Antoine
Le mar. 12 mars 2024 à 08:47, Miller Puckette mpuckette@cloud.ucsd.edu a écrit :
To Pd dev -
I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March. As usual I plan to merge in "devel" and "Documentation" - in fact I should do a first merge rather soon, assuming things are in a good state for merging.
I'm planning to add a couple of features: 1. message to Pd to toggle between GUI and no-GUI -- perhaps with a way to reset the GUI startup command -- so that if you have a headless installation that's doing something funny you can pop it open and look; and 2. improvements to the "pointer" object to make it easier to get around data structures, and possibly a menu extension for dragging new "data" onto the screen; 3. an optional pop-up display showing (x,y) coordinates of object or data knob being dragged.
Incidentally: I just noticed that the IEM slider object (and proabbly other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm..
cheers
Miller
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
I strongly endorse both PRs :)
Fractional zoom levels would be a game changer! The current integer zoom levels are pretty much useless in practice because typical scaling factors are more like 125% or 150%.
A knob is such a basic UI element for audio applications. I really think this should be part of Pd vanilla and not require some external. It isn't (only) about aesthetics; knobs have clear advantages over sliders in many situations as they allow to map the same range into a much smaller space. Just think about a simple mixer strip!
Christof
On 13.03.2024 12:18, Antoine Rousseau wrote:
Miller,
Could I also have your feelings about these 2 PR:
- https://github.com/pure-data/pure-data/pull/1659: modern canvas zoom
and scroll
- https://github.com/pure-data/pure-data/pull/1738: round knob GUI
thanks!
Antoine
Le mar. 12 mars 2024 à 08:47, Miller Puckette mpuckette@cloud.ucsd.edu a écrit :
To Pd dev - I'm thinking of making a release mid April (assuming things go well) and so I should probably call for a freeze late March. As usual I plan to merge in "devel" and "Documentation" - in fact I should do a first merge rather soon, assuming things are in a good state for merging. I'm planning to add a couple of features: 1. message to Pd to toggle between GUI and no-GUI -- perhaps with a way to reset the GUI startup command -- so that if you have a headless installation that's doing something funny you can pop it open and look; and 2. improvements to the "pointer" object to make it easier to get around data structures, and possibly a menu extension for dragging new "data" onto the screen; 3. an optional pop-up display showing (x,y) coordinates of object or data knob being dragged. Incidentally: I just noticed that the IEM slider object (and proabbly other EM GUIs) spits out a number when clicked upon, even if not dragged. Is this desirable behavior? It caught me out buit perhaps other users are actually wanting to be able to click on a control to repeat its value. Hmm.. cheers Miller _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Alexandre Torres Porres -
Antoine Rousseau -
Benjamin Wesch -
Christof Ressi -
Miller Puckette -
Roman Haefeli