Hi,
Miller's comment in https://github.com/pure-data/pure-data/issues/2514#issuecomment-2888313583 suggests that Pd 0.56 will be release soon? Is this true? If yes, have I missed the announcement?
Cheers,
Christof
As always, once I think there's enough new stuff to warrant getting a release out I start putting out 'test' versions (which I announce). But yes, I'd like to get a release out in a month or so if I can.
cheers Miller
On 5/17/25 5:25 PM, Christof Ressi wrote:
Hi,
Miller's comment in https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/25... suggests that Pd 0.56 will be release soon? Is this true? If yes, have I missed the announcement?
Cheers,
Christof
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
Hi Miller,
On 17.05.2025 18:33, Miller Puckette via Pd-dev wrote:
As always, once I think there's enough new stuff to warrant getting a release out I start putting out 'test' versions (which I announce). But yes, I'd like to get a release out in a month or so if I can.
Good to know!
With "announce" I didn't mean the official (test-)release announcements, but rather an announcement on the dev list about an upcoming release. I think last time you actually did this. I was just surprised to find out with a random comment on GitHub. Just keep in mind that some of us have jobs, kids, projects, etc. and we need to plan ahead if we should participate in preparing PRs, testing and bugfixing.
That being said, one month is not too bad. When I read your comment ("P.S. I think this is the only blocking issue for Pd 0.56"), I thought the release was just round the corner. I also thought that you don't want to include any more PRs, which I hope is not the case :)
Side note: we have already discussed this a few times, but it would be *really* great if we could review/merge PRs on a more regular basis. Ideally, feature PRs would get merged in a dedicated branch, so that we can still make bugfix releases from the master branch.
---
I will use this occasion to point out that it has been almost 2 years since the introduction of multi-channel processing and it is still far from complete. Here are some PRs of mine that would implement some missing multi-channel capabilities:
[readsf~]/[writesf~]: https://github.com/pure-data/pure-data/pull/2052
[delwrite~]/[delread~]: https://github.com/pure-data/pure-data/pull/2049
table objects: https://github.com/pure-data/pure-data/pull/2058
[print~]/[snapshot~]/[sig~]: https://github.com/pure-data/pure-data/pull/1978
This PRs are all complete and tested. They just need to be reviewed and merged (or rejected :)
Of course, I would be great to also add some badly needed [snake~] methods, see https://github.com/pure-data/pure-data/issues/1996, but I guess we have to postpone this to Pd 0.57?
---
Finally, there are some other PRs of mine that might be considered:
- new API function pd_findclassbyname(): https://github.com/pure-data/pure-data/pull/2535
- implement missing perform8 methods in d_math: https://github.com/pure-data/pure-data/pull/2497
- new API functions for thread-safe messaging: https://github.com/pure-data/pure-data/pull/2303
- [print]: specify log level and target object: https://github.com/pure-data/pure-data/pull/2228
- [readsf~]: add third outlet for soundfile info: https://github.com/pure-data/pure-data/pull/2206
- signal comparison/logical operators (with multichannel support): https://github.com/pure-data/pure-data/pull/2054
- [clone] improvements: https://github.com/pure-data/pure-data/pull/2053
- [poly] improvements: https://github.com/pure-data/pure-data/pull/661
Cheers,
Christof
cheers Miller
On 5/17/25 5:25 PM, Christof Ressi wrote:
Hi,
Miller's comment in https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/25... suggests that Pd 0.56 will be release soon? Is this true? If yes, have I missed the announcement?
Cheers,
Christof
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/27VJD4HYTKO...
Em sáb., 17 de mai. de 2025 às 16:26, Christof Ressi info@christofressi.com escreveu:
I will use this occasion to point out that it has been almost 2 years since the introduction of multi-channel processing and it is still far from complete.
+1
Yeah, still feels unfinished business to me :) and I look forward to some of the PRs suggested by Christof.
My current behavior (for better or worse) is to get to a point where I think 'master' is stable and has "enough" changes to warrant going through a release cycle. Then I go through PRs and bug reports, fixing what I can and adopting whatever looks like it won't slow me down too much. (I really should read all the PRs line by line but if I tried to do that there would never be another release again). This often takes a week or so.
Then I start putting out 'test releases' which is my invitation to the whole world to find whatever problems they can. That phase typically lasts a month or so, but I can leave things in that state as long as necessary for everyone to have a look and make sure their patches are happy and/or even look over the code to their satisfaction. If anyone tells me to please hold off making the "stable" release because they need more time I'll generally be happy to do that.
I have to think more about whether it makes sense to make a branch where PRs get merged before I have time to thoroughly vet them. It sounds like it would speed things up, but as you've probably figured out I care more about having the best design we can get to than getting there faster (and possibly getting stuck having to stay compatible with a bad initial choice. See [timer] :)
cheers Miller
On 5/17/25 9:26 PM, Christof Ressi wrote:
Hi Miller,
On 17.05.2025 18:33, Miller Puckette via Pd-dev wrote:
As always, once I think there's enough new stuff to warrant getting a release out I start putting out 'test' versions (which I announce). But yes, I'd like to get a release out in a month or so if I can.
Good to know!
With "announce" I didn't mean the official (test-)release announcements, but rather an announcement on the dev list about an upcoming release. I think last time you actually did this. I was just surprised to find out with a random comment on GitHub. Just keep in mind that some of us have jobs, kids, projects, etc. and we need to plan ahead if we should participate in preparing PRs, testing and bugfixing.
That being said, one month is not too bad. When I read your comment ("P.S. I think this is the only blocking issue for Pd 0.56"), I thought the release was just round the corner. I also thought that you don't want to include any more PRs, which I hope is not the case :)
Side note: we have already discussed this a few times, but it would be *really* great if we could review/merge PRs on a more regular basis. Ideally, feature PRs would get merged in a dedicated branch, so that we can still make bugfix releases from the master branch.
I will use this occasion to point out that it has been almost 2 years since the introduction of multi-channel processing and it is still far from complete. Here are some PRs of mine that would implement some missing multi-channel capabilities:
[readsf~]/[writesf~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2052...
[delwrite~]/[delread~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2049...
table objects: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2058...
[print~]/[snapshot~]/[sig~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1978...
This PRs are all complete and tested. They just need to be reviewed and merged (or rejected :)
Of course, I would be great to also add some badly needed [snake~] methods, see https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/19... , but I guess we have to postpone this to Pd 0.57?
Finally, there are some other PRs of mine that might be considered:
- new API function pd_findclassbyname():
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2535...
- implement missing perform8 methods in d_math:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2497...
- new API functions for thread-safe messaging:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2303...
- [print]: specify log level and target object:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2228...
- [readsf~]: add third outlet for soundfile info:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2206...
- signal comparison/logical operators (with multichannel support):
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2054...
- [clone] improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2053...
- [poly] improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/661_...
Cheers,
Christof
cheers Miller
On 5/17/25 5:25 PM, Christof Ressi wrote:
Hi,
Miller's comment in https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/25... suggests that Pd 0.56 will be release soon? Is this true? If yes, have I missed the announcement?
Cheers,
Christof
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
Hi,
thanks for clarifying!
Then I go through PRs and bug reports, fixing what I can and adopting whatever looks like it won't slow me down too much. (I really should read all the PRs line by line but if I tried to do that there would never be another release again). This often takes a week or so.
Here's the thing: if you announce this "merge window" in advance, we can give you a list of prioritized PRs and also make sure they are in good shape. Then you wouldn't have to go through all PRs yourself. In fact, that's what you did last time with Pd 0.55 (after I complained the previous time :) and I found it really helpful!
Again, keep in mind that some us might be in the final stages of a project, be on vacation or have a sick child at home. (In my case, the chance for one of these things to be true is rather high at the moment.) If we miss this one week merge window for feature PRs, it usually means we have to wait for another whole year...
BTW, where are we now in the release cycle? Is it still open for feature PRs? Is there a chance to improve multichannel support for Pd 0.56?
Then I start putting out 'test releases' which is my invitation to the whole world to find whatever problems they can. That phase typically lasts a month or so, but I can leave things in that state as long as necessary for everyone to have a look and make sure their patches are happy and/or even look over the code to their satisfaction. If anyone tells me to please hold off making the "stable" release because they need more time I'll generally be happy to do that.
That's cool, but here we are only talking about bug fixes right? IIRC test-release has always meant feature freeze.
I have to think more about whether it makes sense to make a branch where PRs get merged before I have time to thoroughly vet them.
That's not what I meant at all! Of course, PRs should only be merged into the "experimental branch"*) once they have been thoroughly reviewed (by you)!
In fact, I don't really see how merging feature PRs in a tight one-week window would be better for quality control... Since we would actually be using that experimental branch during development of our PRs, we might catch potential issues (also design issues!) well ahead of time. Wouldn't this be less stressful? Anyway, I think this would be a great topic to discuss in a dev meeting :)
It sounds like it would speed things up, but as you've probably figured out I care more about having the best design we can get to than getting there faster (and possibly getting stuck having to stay compatible with a bad initial choice. See [timer] :)
cheers Miller
Cheers,
Christof
*) typically that would be the develop branch, but our develop branch currently serves a different role.
On 5/17/25 9:26 PM, Christof Ressi wrote:
Hi Miller,
On 17.05.2025 18:33, Miller Puckette via Pd-dev wrote:
As always, once I think there's enough new stuff to warrant getting a release out I start putting out 'test' versions (which I announce). But yes, I'd like to get a release out in a month or so if I can.
Good to know!
With "announce" I didn't mean the official (test-)release announcements, but rather an announcement on the dev list about an upcoming release. I think last time you actually did this. I was just surprised to find out with a random comment on GitHub. Just keep in mind that some of us have jobs, kids, projects, etc. and we need to plan ahead if we should participate in preparing PRs, testing and bugfixing.
That being said, one month is not too bad. When I read your comment ("P.S. I think this is the only blocking issue for Pd 0.56"), I thought the release was just round the corner. I also thought that you don't want to include any more PRs, which I hope is not the case :)
Side note: we have already discussed this a few times, but it would be *really* great if we could review/merge PRs on a more regular basis. Ideally, feature PRs would get merged in a dedicated branch, so that we can still make bugfix releases from the master branch.
I will use this occasion to point out that it has been almost 2 years since the introduction of multi-channel processing and it is still far from complete. Here are some PRs of mine that would implement some missing multi-channel capabilities:
[readsf~]/[writesf~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2052...
[delwrite~]/[delread~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2049...
table objects: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2058...
[print~]/[snapshot~]/[sig~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1978...
This PRs are all complete and tested. They just need to be reviewed and merged (or rejected :)
Of course, I would be great to also add some badly needed [snake~] methods, see https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/19... , but I guess we have to postpone this to Pd 0.57?
Finally, there are some other PRs of mine that might be considered:
- new API function pd_findclassbyname():
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2535...
- implement missing perform8 methods in d_math:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2497...
- new API functions for thread-safe messaging:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2303...
- [print]: specify log level and target object:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2228...
- [readsf~]: add third outlet for soundfile info:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2206...
- signal comparison/logical operators (with multichannel support):
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2054...
- [clone] improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2053...
- [poly] improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/661_...
Cheers,
Christof
cheers Miller
On 5/17/25 5:25 PM, Christof Ressi wrote:
Hi,
Miller's comment in https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/25... suggests that Pd 0.56 will be release soon? Is this true? If yes, have I missed the announcement?
Cheers,
Christof
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/OD6TRWLCQZS...
One thing i want to do is to get on a *much faster* release cycle so that there's not a have-to-do-it-now-or-wait-a-year issue :)
On 5/18/25 3:17 PM, Christof Ressi wrote:
Hi,
thanks for clarifying!
Then I go through PRs and bug reports, fixing what I can and adopting whatever looks like it won't slow me down too much. (I really should read all the PRs line by line but if I tried to do that there would never be another release again). This often takes a week or so.
Here's the thing: if you announce this "merge window" in advance, we can give you a list of prioritized PRs and also make sure they are in good shape. Then you wouldn't have to go through all PRs yourself. In fact, that's what you did last time with Pd 0.55 (after I complained the previous time :) and I found it really helpful!
Again, keep in mind that some us might be in the final stages of a project, be on vacation or have a sick child at home. (In my case, the chance for one of these things to be true is rather high at the moment.) If we miss this one week merge window for feature PRs, it usually means we have to wait for another whole year...
BTW, where are we now in the release cycle? Is it still open for feature PRs? Is there a chance to improve multichannel support for Pd 0.56?
Then I start putting out 'test releases' which is my invitation to the whole world to find whatever problems they can. That phase typically lasts a month or so, but I can leave things in that state as long as necessary for everyone to have a look and make sure their patches are happy and/or even look over the code to their satisfaction. If anyone tells me to please hold off making the "stable" release because they need more time I'll generally be happy to do that.
That's cool, but here we are only talking about bug fixes right? IIRC test-release has always meant feature freeze.
I have to think more about whether it makes sense to make a branch where PRs get merged before I have time to thoroughly vet them.
That's not what I meant at all! Of course, PRs should only be merged into the "experimental branch"*) once they have been thoroughly reviewed (by you)!
In fact, I don't really see how merging feature PRs in a tight one-week window would be better for quality control... Since we would actually be using that experimental branch during development of our PRs, we might catch potential issues (also design issues!) well ahead of time. Wouldn't this be less stressful? Anyway, I think this would be a great topic to discuss in a dev meeting :)
It sounds like it would speed things up, but as you've probably figured out I care more about having the best design we can get to than getting there faster (and possibly getting stuck having to stay compatible with a bad initial choice. See [timer] :)
cheers Miller
Cheers,
Christof
*) typically that would be the develop branch, but our develop branch currently serves a different role.
On 5/17/25 9:26 PM, Christof Ressi wrote:
Hi Miller,
On 17.05.2025 18:33, Miller Puckette via Pd-dev wrote:
As always, once I think there's enough new stuff to warrant getting a release out I start putting out 'test' versions (which I announce). But yes, I'd like to get a release out in a month or so if I can.
Good to know!
With "announce" I didn't mean the official (test-)release announcements, but rather an announcement on the dev list about an upcoming release. I think last time you actually did this. I was just surprised to find out with a random comment on GitHub. Just keep in mind that some of us have jobs, kids, projects, etc. and we need to plan ahead if we should participate in preparing PRs, testing and bugfixing.
That being said, one month is not too bad. When I read your comment ("P.S. I think this is the only blocking issue for Pd 0.56"), I thought the release was just round the corner. I also thought that you don't want to include any more PRs, which I hope is not the case :)
Side note: we have already discussed this a few times, but it would be *really* great if we could review/merge PRs on a more regular basis. Ideally, feature PRs would get merged in a dedicated branch, so that we can still make bugfix releases from the master branch.
I will use this occasion to point out that it has been almost 2 years since the introduction of multi-channel processing and it is still far from complete. Here are some PRs of mine that would implement some missing multi-channel capabilities:
[readsf~]/[writesf~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2052...
[delwrite~]/[delread~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2049...
table objects: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2058...
[print~]/[snapshot~]/[sig~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1978...
This PRs are all complete and tested. They just need to be reviewed and merged (or rejected :)
Of course, I would be great to also add some badly needed [snake~] methods, see https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/19... , but I guess we have to postpone this to Pd 0.57?
Finally, there are some other PRs of mine that might be considered:
- new API function pd_findclassbyname():
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2535...
- implement missing perform8 methods in d_math:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2497...
- new API functions for thread-safe messaging:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2303...
- [print]: specify log level and target object:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2228...
- [readsf~]: add third outlet for soundfile info:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2206...
- signal comparison/logical operators (with multichannel support):
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2054...
- [clone] improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2053...
- [poly] improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/661_...
Cheers,
Christof
cheers Miller
On 5/17/25 5:25 PM, Christof Ressi wrote:
Hi,
Miller's comment in https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/25... suggests that Pd 0.56 will be release soon? Is this true? If yes, have I missed the announcement?
Cheers,
Christof
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
I didn't dare to ask about that, but that would help a lot indeed :)
On 18.05.2025 15:32, Miller Puckette via Pd-dev wrote:
One thing i want to do is to get on a *much faster* release cycle so that there's not a have-to-do-it-now-or-wait-a-year issue :)
On 5/18/25 3:17 PM, Christof Ressi wrote:
Hi,
thanks for clarifying!
Then I go through PRs and bug reports, fixing what I can and adopting whatever looks like it won't slow me down too much. (I really should read all the PRs line by line but if I tried to do that there would never be another release again). This often takes a week or so.
Here's the thing: if you announce this "merge window" in advance, we can give you a list of prioritized PRs and also make sure they are in good shape. Then you wouldn't have to go through all PRs yourself. In fact, that's what you did last time with Pd 0.55 (after I complained the previous time :) and I found it really helpful!
Again, keep in mind that some us might be in the final stages of a project, be on vacation or have a sick child at home. (In my case, the chance for one of these things to be true is rather high at the moment.) If we miss this one week merge window for feature PRs, it usually means we have to wait for another whole year...
BTW, where are we now in the release cycle? Is it still open for feature PRs? Is there a chance to improve multichannel support for Pd 0.56?
Then I start putting out 'test releases' which is my invitation to the whole world to find whatever problems they can. That phase typically lasts a month or so, but I can leave things in that state as long as necessary for everyone to have a look and make sure their patches are happy and/or even look over the code to their satisfaction. If anyone tells me to please hold off making the "stable" release because they need more time I'll generally be happy to do that.
That's cool, but here we are only talking about bug fixes right? IIRC test-release has always meant feature freeze.
I have to think more about whether it makes sense to make a branch where PRs get merged before I have time to thoroughly vet them.
That's not what I meant at all! Of course, PRs should only be merged into the "experimental branch"*) once they have been thoroughly reviewed (by you)!
In fact, I don't really see how merging feature PRs in a tight one-week window would be better for quality control... Since we would actually be using that experimental branch during development of our PRs, we might catch potential issues (also design issues!) well ahead of time. Wouldn't this be less stressful? Anyway, I think this would be a great topic to discuss in a dev meeting :)
It sounds like it would speed things up, but as you've probably figured out I care more about having the best design we can get to than getting there faster (and possibly getting stuck having to stay compatible with a bad initial choice. See [timer] :)
cheers Miller
Cheers,
Christof
*) typically that would be the develop branch, but our develop branch currently serves a different role.
On 5/17/25 9:26 PM, Christof Ressi wrote:
Hi Miller,
On 17.05.2025 18:33, Miller Puckette via Pd-dev wrote:
As always, once I think there's enough new stuff to warrant getting a release out I start putting out 'test' versions (which I announce). But yes, I'd like to get a release out in a month or so if I can.
Good to know!
With "announce" I didn't mean the official (test-)release announcements, but rather an announcement on the dev list about an upcoming release. I think last time you actually did this. I was just surprised to find out with a random comment on GitHub. Just keep in mind that some of us have jobs, kids, projects, etc. and we need to plan ahead if we should participate in preparing PRs, testing and bugfixing.
That being said, one month is not too bad. When I read your comment ("P.S. I think this is the only blocking issue for Pd 0.56"), I thought the release was just round the corner. I also thought that you don't want to include any more PRs, which I hope is not the case :)
Side note: we have already discussed this a few times, but it would be *really* great if we could review/merge PRs on a more regular basis. Ideally, feature PRs would get merged in a dedicated branch, so that we can still make bugfix releases from the master branch.
I will use this occasion to point out that it has been almost 2 years since the introduction of multi-channel processing and it is still far from complete. Here are some PRs of mine that would implement some missing multi-channel capabilities:
[readsf~]/[writesf~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2052...
[delwrite~]/[delread~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2049...
table objects: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2058...
[print~]/[snapshot~]/[sig~]: https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/1978...
This PRs are all complete and tested. They just need to be reviewed and merged (or rejected :)
Of course, I would be great to also add some badly needed [snake~] methods, see https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/19... , but I guess we have to postpone this to Pd 0.57?
Finally, there are some other PRs of mine that might be considered:
- new API function pd_findclassbyname():
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2535...
- implement missing perform8 methods in d_math:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2497...
- new API functions for thread-safe messaging:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2303...
- [print]: specify log level and target object:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2228...
- [readsf~]: add third outlet for soundfile info:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2206...
- signal comparison/logical operators (with multichannel support):
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2054...
- [clone] improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2053...
- [poly] improvements:
https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/661_...
Cheers,
Christof
cheers Miller
On 5/17/25 5:25 PM, Christof Ressi wrote:
Hi,
Miller's comment in https://urldefense.com/v3/__https://github.com/pure-data/pure-data/issues/25... suggests that Pd 0.56 will be release soon? Is this true? If yes, have I missed the announcement?
Cheers,
Christof
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/DPKRTRTTQJJ...
To Pd dev -
I commented on one Pr but this seems like a more general question: in PRs https://github.com/pure-data/pure-data/pull/2049 and https://github.com/pure-data/pure-data/pull/2058 there are "channels" methods to set the number of channels for delwrite~, tabread~ and tabread4~ - why isn't the desired number of channels for these simply inferred from the input signal?
(In the case of delwrite~ perhaps this is because delread~ objects might get sorted before it's clear how many channels delwrite~ will see in its input. But I don't think this should be a problem with the table readers).
And anyway, why set by a message and not in a creation argument? As far as I can determine we're far from being able to make patches with run-time-determined numbers of channels - and I'd rather avoid doing that unless there's great demand since it will greatly complicate things.
thanks Miller
Hi Miller,
I'm currently on a conference, but I will take a look and reply tomorrow night on the train.
In the meantime, thanks a lot for the merges so far!
Cheers,
Christof
On 19.05.2025 11:06, Miller Puckette via Pd-dev wrote:
To Pd dev -
I commented on one Pr but this seems like a more general question: in PRs https://github.com/pure-data/pure-data/pull/2049 and https://github.com/pure-data/pure-data/pull/2058 there are "channels" methods to set the number of channels for delwrite~, tabread~ and tabread4~ - why isn't the desired number of channels for these simply inferred from the input signal?
(In the case of delwrite~ perhaps this is because delread~ objects might get sorted before it's clear how many channels delwrite~ will see in its input. But I don't think this should be a problem with the table readers).
And anyway, why set by a message and not in a creation argument? As far as I can determine we're far from being able to make patches with run-time-determined numbers of channels - and I'd rather avoid doing that unless there's great demand since it will greatly complicate things.
thanks Miller
pd-dev@lists.iem.at - the Pd developers' mailinglist https://lists.iem.at/hyperkitty/list/pd-dev@lists.iem.at/message/43IBETTMNQA...
I agree with this
On May 18, 2025, at 3:17 PM, Christof Ressi info@christofressi.com wrote:
Hi,
thanks for clarifying!
Then I go through PRs and bug reports, fixing what I can and adopting whatever looks like it won't slow me down too much. (I really should read all the PRs line by line but if I tried to do that there would never be another release again). This often takes a week or so.
Here's the thing: if you announce this "merge window" in advance, we can give you a list of prioritized PRs and also make sure they are in good shape. Then you wouldn't have to go through all PRs yourself. In fact, that's what you did last time with Pd 0.55 (after I complained the previous time :) and I found it really helpful!
Again, keep in mind that some us might be in the final stages of a project, be on vacation or have a sick child at home. (In my case, the chance for one of these things to be true is rather high at the moment.) If we miss this one week merge window for feature PRs, it usually means we have to wait for another whole year...
I agree with this. If we know the general milestones for the next release, we can focus on which PRs are already "far enough along" to try test/merge or bring your attention to regarding design, API, etc. I know for the bigger work, we have tried to do this early enough in stages that it's ready to go by the time the development window starts (soundfile and net objects updates), however like Christof, I can't always jump in quickly.
-------- Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Em dom., 18 de mai. de 2025 às 10:17, Christof Ressi info@christofressi.com escreveu:
if you announce this "merge window" in advance, we can give you a list of prioritized PRs and also make sure they are in good shape.
While we're on the merging season, I got a new abstraction I'm suggesting to add to 'extra' and I'd like others to check it out and test if they are happy with it ;) https://github.com/pure-data/pure-data/pull/2574 it's a simple abstraction to calculate biquad coefficients to be a nice companion to [biquad~] for 9 typical filters. It's thoroughly tested and the math/object just works. You can confirm that but I'd like a check if you're all happy with the design or have any other suggestions or feedback. Luckily we'll be able to check if this is in good shape to be considered for 0.56 ;)
Thanks.
ps. I see I have a lot of work to do now in the doc branch with all the exciting newly merged features :) hang on and I'll get there.
ps2. Let me also have my check of PRs that are already in good shape for consideration for now in a next message.
Hmm.. I just made one of those too... maybe we should compare notes offline and combine the best features of both. I'll send you the think I did offline...
cheers Miller
On 5/19/25 7:13 PM, Alexandre Torres Porres wrote:
Em dom., 18 de mai. de 2025 às 10:17, Christof Ressi info@christofressi.com escreveu:
if you announce this "merge window" in advance, we can give you a list of prioritized PRs and also make sure they are in good shape.
While we're on the merging season, I got a new abstraction I'm suggesting to add to 'extra' and I'd like others to check it out and test if they are happy with it ;) https://github.com/pure-data/pure-data/pull/2574 https://urldefense.com/v3/__https://github.com/pure-data/pure-data/pull/2574__;!!Mih3wA!GLBDbDHfdy-Hx8zQUV_w5UeCWt1oiU4Uxb_5PclPJ9Ef0-ZsoN0rHejbfjMl3k78tu8yFrr99Q$ it's a simple abstraction to calculate biquad coefficients to be a nice companion to [biquad~] for 9 typical filters. It's thoroughly tested and the math/object just works. You can confirm that but I'd like a check if you're all happy with the design or have any other suggestions or feedback. Luckily we'll be able to check if this is in good shape to be considered for 0.56 ;)
Thanks.
ps. I see I have a lot of work to do now in the doc branch with all the exciting newly merged features :) hang on and I'll get there.
ps2. Let me also have my check of PRs that are already in good shape for consideration for now in a next message.
pd-dev@lists.iem.at - the Pd developers' mailinglist https://urldefense.com/v3/__https://lists.iem.at/hyperkitty/list/pd-dev@list...
Em seg., 19 de mai. de 2025 às 14:54, Miller Puckette via Pd-dev < pd-dev@lists.iem.at> escreveu:
Hmm.. I just made one of those too...
Haha, what are the odds? Cool, I'll reply to you offlist.
As for a list of "cool PRs" that I mentioned, I'm focusing on those that bring new features. In an attempt to not flood too much, I picked some that are my favorite and "must have" features/additions/improvements for special consideration.
PRs from others: - improve garrays: add message to hide name, save properties https://github.com/pure-data/pure-data/pull/2427 - 8-bit audio support https://github.com/pure-data/pure-data/pull/2498 - list support for [value] https://github.com/pure-data/pure-data/pull/827 / or at least symbol support which I'm in need pretty badly, see also https://github.com/pure-data/pure-data/pull/817 - Add signal comparison/logical operators https://github.com/pure-data/pure-data/pull/2054
PRs from me: - load seeds based on system time for pseudo random number generators https://github.com/pure-data/pure-data/pull/1719 - allow [symbol] to convert float and lists https://github.com/pure-data/pure-data/pull/987 - Add a 'depth' argument to [namecanvas] https://github.com/pure-data/pure-data/pull/837
Cheers