Hello Everyone,

we would like to bring a question for discussion here and hear your opinions.
This may be slightly long, but bear with me.

The Context: Steven’s parser 3, which has been developed to support and make it easier for new language features to be introduced, is nearly ready to be put into production. All csdtests and regression tests are passing, but we still need to integrate the parallel Csound semantic analysis, and there is a few oddities still around.

The Question: Should we integrate it in Csound 6.17 or should we leave it for Csound 7?

Pros (for 6.17 v. 7.00):
- We can start benefitting from a few new language features (in a ‘preview’ way).
- We generate momentum towards 7.
- We can start familiarising ourselves with this new parser and generate further ideas for 7.
- We can smooth the transition from both a development and user point of view.
- Csound 7 becomes more of a reality than something that keeps being put back to a future date.
- We have done this before and it worked well (Parser 2 was introduced in 5.x and fully used in 6.0).
- We currently do not have the capacity to bring cs7 to production in the next release cycle and we don’t know when we will have it.

Cons(for 6.17 v. 7.00):
- A few features meant for 7 are not implemented yet and may not be possible without further changes.
- There’s work to be done to complete the integration (ParCS for example is broken).
- There may be incompatible API changes in the background that would require an API version bump.

Regarding this last point, I can say that I have tried CsoundQT with the parser3 build and it loads and runs, so I am not sure what the status of these possible API changes is. It was only something that Steven mentioned that might be there but he can’t say exactly at the moment.

So if we go for 6.17,  I will finish the feature/parser3 branch, merging it with develop and we will work to make sure it’s ready for release at some point.

If we defer it to 7.00, then I will merge the feature/parser3 branch into the cs7 branch, and we shift our focus to working on it, but without needing to make any of the code ready for production. We’ll likely start breaking things and then fix them again as we implement what need to do. That work will be slow as we don’t have the capacity to do it within our usual release cycle..

We would appreciate your opinions.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

Hi!

What concerns CsoundQt, I would be interested to try the new parser rather sooner than later so I personally incline rather toward including it in v 6 .17.

greetings,

tarmo

Kontakt Victor Lazzarini (<Victor.Lazzarini@mu.ie>) kirjutas kuupäeval E, 13. september 2021 kell 12:31:

Hello Everyone,

we would like to bring a question for discussion here and hear your opinions.
This may be slightly long, but bear with me.

The Context: Steven’s parser 3, which has been developed to support and make it easier for new language features to be introduced, is nearly ready to be put into production. All csdtests and regression tests are passing, but we still need to integrate the parallel Csound semantic analysis, and there is a few oddities still around.

The Question: Should we integrate it in Csound 6.17 or should we leave it for Csound 7?

Pros (for 6.17 v. 7.00):
- We can start benefitting from a few new language features (in a ‘preview’ way).
- We generate momentum towards 7.
- We can start familiarising ourselves with this new parser and generate further ideas for 7.
- We can smooth the transition from both a development and user point of view.
- Csound 7 becomes more of a reality than something that keeps being put back to a future date.
- We have done this before and it worked well (Parser 2 was introduced in 5.x and fully used in 6.0).
- We currently do not have the capacity to bring cs7 to production in the next release cycle and we don’t know when we will have it.

Cons(for 6.17 v. 7.00):
- A few features meant for 7 are not implemented yet and may not be possible without further changes.
- There’s work to be done to complete the integration (ParCS for example is broken).
- There may be incompatible API changes in the background that would require an API version bump.

Regarding this last point, I can say that I have tried CsoundQT with the parser3 build and it loads and runs, so I am not sure what the status of these possible API changes is. It was only something that Steven mentioned that might be there but he can’t say exactly at the moment.

So if we go for 6.17,  I will finish the feature/parser3 branch, merging it with develop and we will work to make sure it’s ready for release at some point.

If we defer it to 7.00, then I will merge the feature/parser3 branch into the cs7 branch, and we shift our focus to working on it, but without needing to make any of the code ready for production. We’ll likely start breaking things and then fix them again as we implement what need to do. That work will be slow as we don’t have the capacity to do it within our usual release cycle..

We would appreciate your opinions.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

For me this would depend on the features gained now versus features gained later. If there are musically useful features in the current state of the new parser it should be merged now. If all the useful new features are waiting for Csound  7 then the merge should happen in Csound 7.

So what are these features?

Regards,

Mike

On Mon, Sep 13, 2021, 06:54 Tarmo Johannes <trmjhnns@gmail.com> wrote:

Hi!

What concerns CsoundQt, I would be interested to try the new parser rather sooner than later so I personally incline rather toward including it in v 6 .17.

greetings,

tarmo

Kontakt Victor Lazzarini (<Victor.Lazzarini@mu.ie>) kirjutas kuupäeval E, 13. september 2021 kell 12:31:

Hello Everyone,

we would like to bring a question for discussion here and hear your opinions.
This may be slightly long, but bear with me.

The Context: Steven’s parser 3, which has been developed to support and make it easier for new language features to be introduced, is nearly ready to be put into production. All csdtests and regression tests are passing, but we still need to integrate the parallel Csound semantic analysis, and there is a few oddities still around.

The Question: Should we integrate it in Csound 6.17 or should we leave it for Csound 7?

Pros (for 6.17 v. 7.00):
- We can start benefitting from a few new language features (in a ‘preview’ way).
- We generate momentum towards 7.
- We can start familiarising ourselves with this new parser and generate further ideas for 7.
- We can smooth the transition from both a development and user point of view.
- Csound 7 becomes more of a reality than something that keeps being put back to a future date.
- We have done this before and it worked well (Parser 2 was introduced in 5.x and fully used in 6.0).
- We currently do not have the capacity to bring cs7 to production in the next release cycle and we don’t know when we will have it.

Cons(for 6.17 v. 7.00):
- A few features meant for 7 are not implemented yet and may not be possible without further changes.
- There’s work to be done to complete the integration (ParCS for example is broken).
- There may be incompatible API changes in the background that would require an API version bump.

Regarding this last point, I can say that I have tried CsoundQT with the parser3 build and it loads and runs, so I am not sure what the status of these possible API changes is. It was only something that Steven mentioned that might be there but he can’t say exactly at the moment.

So if we go for 6.17,  I will finish the feature/parser3 branch, merging it with develop and we will work to make sure it’s ready for release at some point.

If we defer it to 7.00, then I will merge the feature/parser3 branch into the cs7 branch, and we shift our focus to working on it, but without needing to make any of the code ready for production. We’ll likely start breaking things and then fix them again as we implement what need to do. That work will be slow as we don’t have the capacity to do it within our usual release cycle..

We would appreciate your opinions.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

There are things like structs, types, and a lot more support for function-like syntax, for example (this is one of the
test csds)

struct MyType imaginary:k, real:k, kimaginary, kreal

opcode processMyType(in:MyType):(MyType)
  retVal:MyType init 0, 0, 0, 0
  retVal.imaginary = in.imaginary + 1
  retVal.real = in.real + 1
  retVal.kimaginary = in.kimaginary + 1
  retVal.kreal = in.kreal + 1
  xout retVal
endop

instr 1

var0:MyType init 1, 2, 3, 4
;var1:MyType = init:MyType(0, 0, 1, 1)

var0.imaginary init 5
var0.real init 6
var0.kimaginary init 7
var0.kreal init 9

var0.imaginary += 1
var0.real += 2
var0.kimaginary += 3
var0.kreal += 4

var2:MyType processMyType var0

; this does not work yet...
;var2:MyType = processMyType(var0)

printks "i %d r %d ki %d kr %d\n", 0.2, var0.imaginary, var0.real, var0.kimaginary, var0.kreal
printks "\ti %d r %d ki %d kr %d\n", 0.2, var2.imaginary, var2.real, var2.kimaginary, var2.kreal

endin





========================
Prof. Victor Lazzarini
Maynooth University
Ireland

> On 13 Sep 2021, at 12:37, Michael Gogins <michael.gogins@gmail.com> wrote:
>
> WARNINGThis email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.
> For me this would depend on the features gained now versus features gained later. If there are musically useful features in the current state of the new parser it should be merged now. If all the useful new features are waiting for Csound  7 then the merge should happen in Csound 7.
>
> So what are these features?
>
> Regards,
> Mike
>
> On Mon, Sep 13, 2021, 06:54 Tarmo Johannes <trmjhnns@gmail.com> wrote:
> Hi!
>
> What concerns CsoundQt, I would be interested to try the new parser rather sooner than later so I personally incline rather toward including it in v 6 .17.
>
> greetings,
> tarmo
>
> Kontakt Victor Lazzarini (<Victor.Lazzarini@mu.ie>) kirjutas kuupäeval E, 13. september 2021 kell 12:31:
> Hello Everyone,
>
> we would like to bring a question for discussion here and hear your opinions.
> This may be slightly long, but bear with me.
>
> The Context: Steven’s parser 3, which has been developed to support and make it easier for new language features to be introduced, is nearly ready to be put into production. All csdtests and regression tests are passing, but we still need to integrate the parallel Csound semantic analysis, and there is a few oddities still around.
>
> The Question: Should we integrate it in Csound 6.17 or should we leave it for Csound 7?
>
> Pros (for 6.17 v. 7.00):
> - We can start benefitting from a few new language features (in a ‘preview’ way).
> - We generate momentum towards 7.
> - We can start familiarising ourselves with this new parser and generate further ideas for 7.
> - We can smooth the transition from both a development and user point of view.
> - Csound 7 becomes more of a reality than something that keeps being put back to a future date.
> - We have done this before and it worked well (Parser 2 was introduced in 5.x and fully used in 6.0).
> - We currently do not have the capacity to bring cs7 to production in the next release cycle and we don’t know when we will have it.
>
> Cons(for 6.17 v. 7.00):
> - A few features meant for 7 are not implemented yet and may not be possible without further changes.
> - There’s work to be done to complete the integration (ParCS for example is broken).
> - There may be incompatible API changes in the background that would require an API version bump.
>
> Regarding this last point, I can say that I have tried CsoundQT with the parser3 build and it loads and runs, so I am not sure what the status of these possible API changes is. It was only something that Steven mentioned that might be there but he can’t say exactly at the moment.
>
> So if we go for 6.17,  I will finish the feature/parser3 branch, merging it with develop and we will work to make sure it’s ready for release at some point.
>
> If we defer it to 7.00, then I will merge the feature/parser3 branch into the cs7 branch, and we shift our focus to working on it, but without needing to make any of the code ready for production. We’ll likely start breaking things and then fix them again as we implement what need to do. That work will be slow as we don’t have the capacity to do it within our usual release cycle..
>
> We would appreciate your opinions.
> ========================
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>

Hello Everyone,

we would like to bring a question for discussion here and hear your opinions.
This may be slightly long, but bear with me.

The Context: Steven’s parser 3, which has been developed to support and make it easier for new language features to be introduced, is nearly ready to be put into production. All csdtests and regression tests are passing, but we still need to integrate the parallel Csound semantic analysis, and there is a few oddities still around.

The Question: Should we integrate it in Csound 6.17 or should we leave it for Csound 7?

Pros (for 6.17 v. 7.00):
- We can start benefitting from a few new language features (in a ‘preview’ way).
- We generate momentum towards 7.
- We can start familiarising ourselves with this new parser and generate further ideas for 7.
- We can smooth the transition from both a development and user point of view.
- Csound 7 becomes more of a reality than something that keeps being put back to a future date.
- We have done this before and it worked well (Parser 2 was introduced in 5.x and fully used in 6.0).
- We currently do not have the capacity to bring cs7 to production in the next release cycle and we don’t know when we will have it.

Cons(for 6.17 v. 7.00):
- A few features meant for 7 are not implemented yet and may not be possible without further changes.
- There’s work to be done to complete the integration (ParCS for example is broken).
- There may be incompatible API changes in the background that would require an API version bump.

Regarding this last point, I can say that I have tried CsoundQT with the parser3 build and it loads and runs, so I am not sure what the status of these possible API changes is. It was only something that Steven mentioned that might be there but he can’t say exactly at the moment.

So if we go for 6.17,  I will finish the feature/parser3 branch, merging it with develop and we will work to make sure it’s ready for release at some point.

If we defer it to 7.00, then I will merge the feature/parser3 branch into the cs7 branch, and we shift our focus to working on it, but without needing to make any of the code ready for production. We’ll likely start breaking things and then fix them again as we implement what need to do. That work will be slow as we don’t have the capacity to do it within our usual release cycle..

We would appreciate your opinions.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

The thing is that Cs7 will not be in a working condition for a good while, whereas 6.17 will be.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 13 Sep 2021, at 13:08, Rory Walsh <rorywalsh@ear.ie> wrote:



*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

If we swap out the parser, I think it constitutes a new version. I would be in favour of a clean break. It also means we can continue to publish bug-fix releases for Csound 6 without having to worry about new parser side-effects. Creating a new Cs7 branch doesn't mean users have to wait before they can try out the new features. We have CI builds; anyone with an internet connection can start testing Cs7 as soon as the first commit happens. 

On Mon, 13 Sept 2021 at 12:38, Michael Gogins <michael.gogins@gmail.com> wrote:

For me this would depend on the features gained now versus features gained later. If there are musically useful features in the current state of the new parser it should be merged now. If all the useful new features are waiting for Csound  7 then the merge should happen in Csound 7.

So what are these features?

Regards,

Mike

On Mon, Sep 13, 2021, 06:54 Tarmo Johannes <trmjhnns@gmail.com> wrote:

Hi!

What concerns CsoundQt, I would be interested to try the new parser rather sooner than later so I personally incline rather toward including it in v 6 .17.

greetings,

tarmo

Kontakt Victor Lazzarini (<Victor.Lazzarini@mu.ie>) kirjutas kuupäeval E, 13. september 2021 kell 12:31:

Hello Everyone,

we would like to bring a question for discussion here and hear your opinions.
This may be slightly long, but bear with me.

The Context: Steven’s parser 3, which has been developed to support and make it easier for new language features to be introduced, is nearly ready to be put into production. All csdtests and regression tests are passing, but we still need to integrate the parallel Csound semantic analysis, and there is a few oddities still around.

The Question: Should we integrate it in Csound 6.17 or should we leave it for Csound 7?

Pros (for 6.17 v. 7.00):
- We can start benefitting from a few new language features (in a ‘preview’ way).
- We generate momentum towards 7.
- We can start familiarising ourselves with this new parser and generate further ideas for 7.
- We can smooth the transition from both a development and user point of view.
- Csound 7 becomes more of a reality than something that keeps being put back to a future date.
- We have done this before and it worked well (Parser 2 was introduced in 5.x and fully used in 6.0).
- We currently do not have the capacity to bring cs7 to production in the next release cycle and we don’t know when we will have it.

Cons(for 6.17 v. 7.00):
- A few features meant for 7 are not implemented yet and may not be possible without further changes.
- There’s work to be done to complete the integration (ParCS for example is broken).
- There may be incompatible API changes in the background that would require an API version bump.

Regarding this last point, I can say that I have tried CsoundQT with the parser3 build and it loads and runs, so I am not sure what the status of these possible API changes is. It was only something that Steven mentioned that might be there but he can’t say exactly at the moment.

So if we go for 6.17,  I will finish the feature/parser3 branch, merging it with develop and we will work to make sure it’s ready for release at some point.

If we defer it to 7.00, then I will merge the feature/parser3 branch into the cs7 branch, and we shift our focus to working on it, but without needing to make any of the code ready for production. We’ll likely start breaking things and then fix them again as we implement what need to do. That work will be slow as we don’t have the capacity to do it within our usual release cycle..

We would appreciate your opinions.
========================
Prof. Victor Lazzarini
Maynooth University
Ireland

yes, we have already done that. But if we take previous version upgrades experiences, we'll probably be breaking stuff left, right and center before we can move forward.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 14 Sep 2021, at 09:30, Rory Walsh <rorywalsh@ear.ie> wrote:



The thing is that Cs7 will not be in a working condition for a good while, whereas 6.17 will be.

I was under the impression that you would simply create a new cs7 branch, merge 6.17 into it and continue from there, which would be the same as continuing in 6.17, but offers a cleaner break? 

Thanks for this. I understand your point of view, and there is sense in it.

I just want to point out that, while not denying what you say, I don't agree that Csound is particularly buggy. In fact, on the contrary, it is quite mature as a technology.

The bugs you are reporting are to do with the web platform and that is of course on the edge, particularly as they have moved to a different compiler and are reworking that API. I can't comment on Cabbage bugs because that is a third party project we do not have anything to do with (apart from supporting), it is not Csound. 

It is great that you are supporting that effort, and as you can see that bit has not yet been released so you are working with what can best be described as beta or even possibly alpha code. No wonder you are having second thoughts about using it, it's not really in production shape. However, this is not representative of the Csound code as a whole.

If you look at the Csound issue tracker, you will not see much action beyond these cutting edge platforms/tech. In fact, excluding web csound, I don't think there are any bug tickets currently open (we tend to try and address these as quickly as possible) and certainly no show stoppers as far as I can see (if there are I am happy to be corrected and will address them immediately).

Anyway, thanks again for your comments.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 15 Sep 2021, at 06:24, andy fillebrown <andy.fillebrown@gmail.com> wrote:



Thanks for opening this up for discussion.

tldr; I love Csound but I'm tired of running into its bugs. I vote for keeping the current parser for 6.17 if the new parser can't coexist with it.

I very much want to use the new parser features but I do not want to risk the stability of 6.17. There are many changes in 6.17 that I am waiting for and it would be frustrating to me if it brought in new issues due to the new parser. I do not want to be stuck on 6.16 until the new parser issues are fixed.

If there are not enough dev resources to maintain two releases then I vote for stability over new parser.

Is there no way to put the new parser behind a command line argument? Didn't the version 5 to 6 parser change work that way? If that's not the case for version 6 to 7 then I'd rather see it pushed to 7, especially since the API would change. Maybe make 7 more of a transition/experimental release and move quickly to 8? Just a thought

Regardless of what is decided I think it's important to say that I feel like Csound is gaining a fair amount of momentum in the past few years due to the decisions made in the past by the lead devs, e.g. the move to Github, switching from Scons to CMake, and the relatively smooth transition from version 5 to 6. In hindsight these have clearly been the right decisions, so I'm not too concerned about how the new parser is handled. I trust that the devs have the community's best interests in mind.

That being said, from my point of view it would be a shame to lose the momentum gained from those good past decisions by replacing the relatively stable parser with an unknown. Csound has a history of being buggy and as an artist, my choice to use Csound and Cabbage has been the biggest risk in my toolchain due to the number of bugs I have encountered. I have had to stop working on my project several times this past year to fix issues in Cabbage and Csound, and two weeks ago I came very close to giving up on using Csound WASM in my WebXR project due to show-stopping memory issues. Fortunately, I persisted and was able to fix the issues, so I'm in a good place now and I'm moving forward on my project nicely. The dev fatigue I'm feeling from the Cabbage and Csound bugs is real, though. I very much want to just make stuff with these awesome tools you all have given us, and I feel like version 6 is just now starting to become satisfactorily stable enough to do that. I'm very much looking forward to the maturity of the next release and I feel like what's going to keep the momentum going the best right now is stable releases with fewer bugs. That is more important to me than the new parser.

Thanks for listening,

~ Andy Fillebrown / docEdub

On Tue, Sep 14, 2021 at 1:20 PM Pete Goodeve <pete.goodeve@computer.org> wrote:

A strong +1 on this from me.  Iain has echoed my own opinion far more
clearly than I could!

Thanks!

        -- Pete --

On Tue, Sep 14, 2021 at 07:32:18AM -0700, Iain Duncan wrote:
> Hi Victor and others, of course I'm not a csound dev and nor have I been
> involved for many years (though I'm using it again now), so take what I say
> with a grain of salt. I am, FWIW, a technical due diligence consultant to
> software companies getting major investments or being acquired so talking
> with software companies about their releases cycles, development processes,
> etc, is my day job now, for everything from tiny shops to $1B monsters. And
> an open source author of a much much smaller project, haha. My thoughts
> from the sidelines:
>
> - The new parser sounds like a great step forward, kudos!
> - If there is any risk of the merge of the new parser breaking things in 6,
> when it comes out, because of uncaught backwards incompatibility at this
> point, I think it should not be merged to 6. This is the kind of thing that
> alienates users and creates negative impressions that can be very hard to
> get over later, in my experience.
> - As above for the API. People using the API in apps and frontends expect
> API stability unless there is a major version number change. Breaking that
> expectation can lose you some of the most important users, in my humble
> opinion.
> - The million dollar question: does the csound dev community/system have
> the QA infrastructure/process in place to ensure the above won't be issues?
> Please do not take that as  a value judgement, automating QA is hard work,
> I honestly don't know what the situation is these days though I can see
> it's much more automated than it was 10-15 years ago. But I think if the
> answer is no or unknown, then merging to 6 is rash.
> - Given the above, is there a compelling reason not to maintain a 6 stable
> and 7-alpha version for some period of overlap?  I see this done sometimes
> in both open source and commercial software for this type of situation.
> When a public stable version is maintained and strictly tested, people are
> much more forgiving about the bleeding edge on the next one. The 7-alpha
> does not have to be 7 *as it is planned now*, it could be 6 with the new
> parser and be the merge target for other features for some period (6
> months, a year, whatever). In my experience, and from people I've spoken
> to, maintaining a second release line is actually less work than it sounds
> like it will be, as so much of the work for the first one is reusable. It
> does not have to lead to the dreaded Python 2 to 3 situation if handled
> properly.
> - An advantage of the above is that the new features become something
> people can see. In my impression, a big problem with projects like csound,
> where the system is very complex and most of the devs are juggling the rest
> of their academic duties and so on, is that the development can come across
> to public users as very hidden, or worse, as if it's not going on, just
> because it's not visible to them in the way they are used to from
> constantly releasing reference projects. Whether we agree with it or not,
> visibility of new features moving along is a big part of what potential new
> users look for. (I am guilty of not handling this well myself and have
> resolved to try to fix it for Scheme for Max after 0.3 this month!)
>
> Them's my two cents Canadian, with no expectation that anyone has any
> reason to listen to me. :-)  Now that I am through my conference/thesis
> first paper, I shall be using Csound more and would be happy to help test
> builds.
>
> iain
>
> On Tue, Sep 14, 2021 at 2:57 AM Victor Lazzarini <Victor.Lazzarini@mu.ie>
> wrote:
>
> > yes, we have already done that. But if we take previous version upgrades
> > experiences, we'll probably be breaking stuff left, right and center before
> > we can move forward.
> >
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> >
> > On 14 Sep 2021, at 09:30, Rory Walsh <rorywalsh@ear.ie> wrote:
> >
> > 
> >
> >> The thing is that Cs7 will not be in a working condition for a good
> >> while, whereas 6.17 will be.
> >>
> >
> > I was under the impression that you would simply create a new cs7 branch,
> > merge 6.17 into it and continue from there, which would be the same as
> > continuing in 6.17, but offers a cleaner break?
> >
> >

To be fair to you Andy, you really push Csound in ways the average users can only dream about. However, it's been a while since you reported any issues with Cabbage. As a member of the Cabbage forum, you know I tend to deal with issues as soon as they appear. And in the times you've made PRs I've never had any issues in merging. I'd be happy if you made more 😀  

It looks like you've switched focus to CsoundWASM at the minute, so maybe you're taking a break from Cabbage. Hopefully by the time you return it will be better than ever ;) 

Your WebXr stuff looks really impressive btw! I'm looking forward to following your progress there. 

On Wed, 15 Sept 2021 at 07:04, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

Thanks for this. I understand your point of view, and there is sense in it.

I just want to point out that, while not denying what you say, I don't agree that Csound is particularly buggy. In fact, on the contrary, it is quite mature as a technology.

The bugs you are reporting are to do with the web platform and that is of course on the edge, particularly as they have moved to a different compiler and are reworking that API. I can't comment on Cabbage bugs because that is a third party project we do not have anything to do with (apart from supporting), it is not Csound. 

It is great that you are supporting that effort, and as you can see that bit has not yet been released so you are working with what can best be described as beta or even possibly alpha code. No wonder you are having second thoughts about using it, it's not really in production shape. However, this is not representative of the Csound code as a whole.

If you look at the Csound issue tracker, you will not see much action beyond these cutting edge platforms/tech. In fact, excluding web csound, I don't think there are any bug tickets currently open (we tend to try and address these as quickly as possible) and certainly no show stoppers as far as I can see (if there are I am happy to be corrected and will address them immediately).

Anyway, thanks again for your comments.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 15 Sep 2021, at 06:24, andy fillebrown <andy.fillebrown@gmail.com> wrote:



Thanks for opening this up for discussion.

tldr; I love Csound but I'm tired of running into its bugs. I vote for keeping the current parser for 6.17 if the new parser can't coexist with it.

I very much want to use the new parser features but I do not want to risk the stability of 6.17. There are many changes in 6.17 that I am waiting for and it would be frustrating to me if it brought in new issues due to the new parser. I do not want to be stuck on 6.16 until the new parser issues are fixed.

If there are not enough dev resources to maintain two releases then I vote for stability over new parser.

Is there no way to put the new parser behind a command line argument? Didn't the version 5 to 6 parser change work that way? If that's not the case for version 6 to 7 then I'd rather see it pushed to 7, especially since the API would change. Maybe make 7 more of a transition/experimental release and move quickly to 8? Just a thought

Regardless of what is decided I think it's important to say that I feel like Csound is gaining a fair amount of momentum in the past few years due to the decisions made in the past by the lead devs, e.g. the move to Github, switching from Scons to CMake, and the relatively smooth transition from version 5 to 6. In hindsight these have clearly been the right decisions, so I'm not too concerned about how the new parser is handled. I trust that the devs have the community's best interests in mind.

That being said, from my point of view it would be a shame to lose the momentum gained from those good past decisions by replacing the relatively stable parser with an unknown. Csound has a history of being buggy and as an artist, my choice to use Csound and Cabbage has been the biggest risk in my toolchain due to the number of bugs I have encountered. I have had to stop working on my project several times this past year to fix issues in Cabbage and Csound, and two weeks ago I came very close to giving up on using Csound WASM in my WebXR project due to show-stopping memory issues. Fortunately, I persisted and was able to fix the issues, so I'm in a good place now and I'm moving forward on my project nicely. The dev fatigue I'm feeling from the Cabbage and Csound bugs is real, though. I very much want to just make stuff with these awesome tools you all have given us, and I feel like version 6 is just now starting to become satisfactorily stable enough to do that. I'm very much looking forward to the maturity of the next release and I feel like what's going to keep the momentum going the best right now is stable releases with fewer bugs. That is more important to me than the new parser.

Thanks for listening,

~ Andy Fillebrown / docEdub

On Tue, Sep 14, 2021 at 1:20 PM Pete Goodeve <pete.goodeve@computer.org> wrote:

A strong +1 on this from me.  Iain has echoed my own opinion far more
clearly than I could!

Thanks!

        -- Pete --

On Tue, Sep 14, 2021 at 07:32:18AM -0700, Iain Duncan wrote:
> Hi Victor and others, of course I'm not a csound dev and nor have I been
> involved for many years (though I'm using it again now), so take what I say
> with a grain of salt. I am, FWIW, a technical due diligence consultant to
> software companies getting major investments or being acquired so talking
> with software companies about their releases cycles, development processes,
> etc, is my day job now, for everything from tiny shops to $1B monsters. And
> an open source author of a much much smaller project, haha. My thoughts
> from the sidelines:
>
> - The new parser sounds like a great step forward, kudos!
> - If there is any risk of the merge of the new parser breaking things in 6,
> when it comes out, because of uncaught backwards incompatibility at this
> point, I think it should not be merged to 6. This is the kind of thing that
> alienates users and creates negative impressions that can be very hard to
> get over later, in my experience.
> - As above for the API. People using the API in apps and frontends expect
> API stability unless there is a major version number change. Breaking that
> expectation can lose you some of the most important users, in my humble
> opinion.
> - The million dollar question: does the csound dev community/system have
> the QA infrastructure/process in place to ensure the above won't be issues?
> Please do not take that as  a value judgement, automating QA is hard work,
> I honestly don't know what the situation is these days though I can see
> it's much more automated than it was 10-15 years ago. But I think if the
> answer is no or unknown, then merging to 6 is rash.
> - Given the above, is there a compelling reason not to maintain a 6 stable
> and 7-alpha version for some period of overlap?  I see this done sometimes
> in both open source and commercial software for this type of situation.
> When a public stable version is maintained and strictly tested, people are
> much more forgiving about the bleeding edge on the next one. The 7-alpha
> does not have to be 7 *as it is planned now*, it could be 6 with the new
> parser and be the merge target for other features for some period (6
> months, a year, whatever). In my experience, and from people I've spoken
> to, maintaining a second release line is actually less work than it sounds
> like it will be, as so much of the work for the first one is reusable. It
> does not have to lead to the dreaded Python 2 to 3 situation if handled
> properly.
> - An advantage of the above is that the new features become something
> people can see. In my impression, a big problem with projects like csound,
> where the system is very complex and most of the devs are juggling the rest
> of their academic duties and so on, is that the development can come across
> to public users as very hidden, or worse, as if it's not going on, just
> because it's not visible to them in the way they are used to from
> constantly releasing reference projects. Whether we agree with it or not,
> visibility of new features moving along is a big part of what potential new
> users look for. (I am guilty of not handling this well myself and have
> resolved to try to fix it for Scheme for Max after 0.3 this month!)
>
> Them's my two cents Canadian, with no expectation that anyone has any
> reason to listen to me. :-)  Now that I am through my conference/thesis
> first paper, I shall be using Csound more and would be happy to help test
> builds.
>
> iain
>
> On Tue, Sep 14, 2021 at 2:57 AM Victor Lazzarini <Victor.Lazzarini@mu.ie>
> wrote:
>
> > yes, we have already done that. But if we take previous version upgrades
> > experiences, we'll probably be breaking stuff left, right and center before
> > we can move forward.
> >
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> >
> > On 14 Sep 2021, at 09:30, Rory Walsh <rorywalsh@ear.ie> wrote:
> >
> > 
> >
> >> The thing is that Cs7 will not be in a working condition for a good
> >> while, whereas 6.17 will be.
> >>
> >
> > I was under the impression that you would simply create a new cs7 branch,
> > merge 6.17 into it and continue from there, which would be the same as
> > continuing in 6.17, but offers a cleaner break?
> >
> >

Good points. To be clear, I think you're all doing a great job with Cabbage and Csound and I'm appreciative of the responsiveness in fixing bugs. I feel like both Cabbage and Csound are in really good shape, and while I'm very much looking forward to the new features in Csound 7, I'm even more looking forward to working with Csound 6 as-is. Csound 6 is very good software right now.

Thank you,

~ Andy Fillebrown / docEdub

On Wed, Sep 15, 2021 at 4:11 AM Rory Walsh <rorywalsh@ear.ie> wrote:

To be fair to you Andy, you really push Csound in ways the average users can only dream about. However, it's been a while since you reported any issues with Cabbage. As a member of the Cabbage forum, you know I tend to deal with issues as soon as they appear. And in the times you've made PRs I've never had any issues in merging. I'd be happy if you made more 😀  

It looks like you've switched focus to CsoundWASM at the minute, so maybe you're taking a break from Cabbage. Hopefully by the time you return it will be better than ever ;) 

Your WebXr stuff looks really impressive btw! I'm looking forward to following your progress there. 

On Wed, 15 Sept 2021 at 07:04, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

Thanks for this. I understand your point of view, and there is sense in it.

I just want to point out that, while not denying what you say, I don't agree that Csound is particularly buggy. In fact, on the contrary, it is quite mature as a technology.

The bugs you are reporting are to do with the web platform and that is of course on the edge, particularly as they have moved to a different compiler and are reworking that API. I can't comment on Cabbage bugs because that is a third party project we do not have anything to do with (apart from supporting), it is not Csound. 

It is great that you are supporting that effort, and as you can see that bit has not yet been released so you are working with what can best be described as beta or even possibly alpha code. No wonder you are having second thoughts about using it, it's not really in production shape. However, this is not representative of the Csound code as a whole.

If you look at the Csound issue tracker, you will not see much action beyond these cutting edge platforms/tech. In fact, excluding web csound, I don't think there are any bug tickets currently open (we tend to try and address these as quickly as possible) and certainly no show stoppers as far as I can see (if there are I am happy to be corrected and will address them immediately).

Anyway, thanks again for your comments.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 15 Sep 2021, at 06:24, andy fillebrown <andy.fillebrown@gmail.com> wrote:



Thanks for opening this up for discussion.

tldr; I love Csound but I'm tired of running into its bugs. I vote for keeping the current parser for 6.17 if the new parser can't coexist with it.

I very much want to use the new parser features but I do not want to risk the stability of 6.17. There are many changes in 6.17 that I am waiting for and it would be frustrating to me if it brought in new issues due to the new parser. I do not want to be stuck on 6.16 until the new parser issues are fixed.

If there are not enough dev resources to maintain two releases then I vote for stability over new parser.

Is there no way to put the new parser behind a command line argument? Didn't the version 5 to 6 parser change work that way? If that's not the case for version 6 to 7 then I'd rather see it pushed to 7, especially since the API would change. Maybe make 7 more of a transition/experimental release and move quickly to 8? Just a thought

Regardless of what is decided I think it's important to say that I feel like Csound is gaining a fair amount of momentum in the past few years due to the decisions made in the past by the lead devs, e.g. the move to Github, switching from Scons to CMake, and the relatively smooth transition from version 5 to 6. In hindsight these have clearly been the right decisions, so I'm not too concerned about how the new parser is handled. I trust that the devs have the community's best interests in mind.

That being said, from my point of view it would be a shame to lose the momentum gained from those good past decisions by replacing the relatively stable parser with an unknown. Csound has a history of being buggy and as an artist, my choice to use Csound and Cabbage has been the biggest risk in my toolchain due to the number of bugs I have encountered. I have had to stop working on my project several times this past year to fix issues in Cabbage and Csound, and two weeks ago I came very close to giving up on using Csound WASM in my WebXR project due to show-stopping memory issues. Fortunately, I persisted and was able to fix the issues, so I'm in a good place now and I'm moving forward on my project nicely. The dev fatigue I'm feeling from the Cabbage and Csound bugs is real, though. I very much want to just make stuff with these awesome tools you all have given us, and I feel like version 6 is just now starting to become satisfactorily stable enough to do that. I'm very much looking forward to the maturity of the next release and I feel like what's going to keep the momentum going the best right now is stable releases with fewer bugs. That is more important to me than the new parser.

Thanks for listening,

~ Andy Fillebrown / docEdub

On Tue, Sep 14, 2021 at 1:20 PM Pete Goodeve <pete.goodeve@computer.org> wrote:

A strong +1 on this from me.  Iain has echoed my own opinion far more
clearly than I could!

Thanks!

        -- Pete --

On Tue, Sep 14, 2021 at 07:32:18AM -0700, Iain Duncan wrote:
> Hi Victor and others, of course I'm not a csound dev and nor have I been
> involved for many years (though I'm using it again now), so take what I say
> with a grain of salt. I am, FWIW, a technical due diligence consultant to
> software companies getting major investments or being acquired so talking
> with software companies about their releases cycles, development processes,
> etc, is my day job now, for everything from tiny shops to $1B monsters. And
> an open source author of a much much smaller project, haha. My thoughts
> from the sidelines:
>
> - The new parser sounds like a great step forward, kudos!
> - If there is any risk of the merge of the new parser breaking things in 6,
> when it comes out, because of uncaught backwards incompatibility at this
> point, I think it should not be merged to 6. This is the kind of thing that
> alienates users and creates negative impressions that can be very hard to
> get over later, in my experience.
> - As above for the API. People using the API in apps and frontends expect
> API stability unless there is a major version number change. Breaking that
> expectation can lose you some of the most important users, in my humble
> opinion.
> - The million dollar question: does the csound dev community/system have
> the QA infrastructure/process in place to ensure the above won't be issues?
> Please do not take that as  a value judgement, automating QA is hard work,
> I honestly don't know what the situation is these days though I can see
> it's much more automated than it was 10-15 years ago. But I think if the
> answer is no or unknown, then merging to 6 is rash.
> - Given the above, is there a compelling reason not to maintain a 6 stable
> and 7-alpha version for some period of overlap?  I see this done sometimes
> in both open source and commercial software for this type of situation.
> When a public stable version is maintained and strictly tested, people are
> much more forgiving about the bleeding edge on the next one. The 7-alpha
> does not have to be 7 *as it is planned now*, it could be 6 with the new
> parser and be the merge target for other features for some period (6
> months, a year, whatever). In my experience, and from people I've spoken
> to, maintaining a second release line is actually less work than it sounds
> like it will be, as so much of the work for the first one is reusable. It
> does not have to lead to the dreaded Python 2 to 3 situation if handled
> properly.
> - An advantage of the above is that the new features become something
> people can see. In my impression, a big problem with projects like csound,
> where the system is very complex and most of the devs are juggling the rest
> of their academic duties and so on, is that the development can come across
> to public users as very hidden, or worse, as if it's not going on, just
> because it's not visible to them in the way they are used to from
> constantly releasing reference projects. Whether we agree with it or not,
> visibility of new features moving along is a big part of what potential new
> users look for. (I am guilty of not handling this well myself and have
> resolved to try to fix it for Scheme for Max after 0.3 this month!)
>
> Them's my two cents Canadian, with no expectation that anyone has any
> reason to listen to me. :-)  Now that I am through my conference/thesis
> first paper, I shall be using Csound more and would be happy to help test
> builds.
>
> iain
>
> On Tue, Sep 14, 2021 at 2:57 AM Victor Lazzarini <Victor.Lazzarini@mu.ie>
> wrote:
>
> > yes, we have already done that. But if we take previous version upgrades
> > experiences, we'll probably be breaking stuff left, right and center before
> > we can move forward.
> >
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> >
> > On 14 Sep 2021, at 09:30, Rory Walsh <rorywalsh@ear.ie> wrote:
> >
> > 
> >
> >> The thing is that Cs7 will not be in a working condition for a good
> >> while, whereas 6.17 will be.
> >>
> >
> > I was under the impression that you would simply create a new cs7 branch,
> > merge 6.17 into it and continue from there, which would be the same as
> > continuing in 6.17, but offers a cleaner break?
> >
> >

Good points. To be clear, I think you're all doing a great job with Cabbage and Csound and I'm appreciative of the responsiveness in fixing bugs. I feel like both Cabbage and Csound are in really good shape, and while I'm very much looking forward to the new features in Csound 7, I'm even more looking forward to working with Csound 6 as-is. Csound 6 is very good software right now.

Thank you,

~ Andy Fillebrown / docEdub

On Wed, Sep 15, 2021 at 4:11 AM Rory Walsh <rorywalsh@ear.ie> wrote:

To be fair to you Andy, you really push Csound in ways the average users can only dream about. However, it's been a while since you reported any issues with Cabbage. As a member of the Cabbage forum, you know I tend to deal with issues as soon as they appear. And in the times you've made PRs I've never had any issues in merging. I'd be happy if you made more 😀  

It looks like you've switched focus to CsoundWASM at the minute, so maybe you're taking a break from Cabbage. Hopefully by the time you return it will be better than ever ;) 

Your WebXr stuff looks really impressive btw! I'm looking forward to following your progress there. 

On Wed, 15 Sept 2021 at 07:04, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

Thanks for this. I understand your point of view, and there is sense in it.

I just want to point out that, while not denying what you say, I don't agree that Csound is particularly buggy. In fact, on the contrary, it is quite mature as a technology.

The bugs you are reporting are to do with the web platform and that is of course on the edge, particularly as they have moved to a different compiler and are reworking that API. I can't comment on Cabbage bugs because that is a third party project we do not have anything to do with (apart from supporting), it is not Csound. 

It is great that you are supporting that effort, and as you can see that bit has not yet been released so you are working with what can best be described as beta or even possibly alpha code. No wonder you are having second thoughts about using it, it's not really in production shape. However, this is not representative of the Csound code as a whole.

If you look at the Csound issue tracker, you will not see much action beyond these cutting edge platforms/tech. In fact, excluding web csound, I don't think there are any bug tickets currently open (we tend to try and address these as quickly as possible) and certainly no show stoppers as far as I can see (if there are I am happy to be corrected and will address them immediately).

Anyway, thanks again for your comments.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 15 Sep 2021, at 06:24, andy fillebrown <andy.fillebrown@gmail.com> wrote:



Thanks for opening this up for discussion.

tldr; I love Csound but I'm tired of running into its bugs. I vote for keeping the current parser for 6.17 if the new parser can't coexist with it.

I very much want to use the new parser features but I do not want to risk the stability of 6.17. There are many changes in 6.17 that I am waiting for and it would be frustrating to me if it brought in new issues due to the new parser. I do not want to be stuck on 6.16 until the new parser issues are fixed.

If there are not enough dev resources to maintain two releases then I vote for stability over new parser.

Is there no way to put the new parser behind a command line argument? Didn't the version 5 to 6 parser change work that way? If that's not the case for version 6 to 7 then I'd rather see it pushed to 7, especially since the API would change. Maybe make 7 more of a transition/experimental release and move quickly to 8? Just a thought

Regardless of what is decided I think it's important to say that I feel like Csound is gaining a fair amount of momentum in the past few years due to the decisions made in the past by the lead devs, e.g. the move to Github, switching from Scons to CMake, and the relatively smooth transition from version 5 to 6. In hindsight these have clearly been the right decisions, so I'm not too concerned about how the new parser is handled. I trust that the devs have the community's best interests in mind.

That being said, from my point of view it would be a shame to lose the momentum gained from those good past decisions by replacing the relatively stable parser with an unknown. Csound has a history of being buggy and as an artist, my choice to use Csound and Cabbage has been the biggest risk in my toolchain due to the number of bugs I have encountered. I have had to stop working on my project several times this past year to fix issues in Cabbage and Csound, and two weeks ago I came very close to giving up on using Csound WASM in my WebXR project due to show-stopping memory issues. Fortunately, I persisted and was able to fix the issues, so I'm in a good place now and I'm moving forward on my project nicely. The dev fatigue I'm feeling from the Cabbage and Csound bugs is real, though. I very much want to just make stuff with these awesome tools you all have given us, and I feel like version 6 is just now starting to become satisfactorily stable enough to do that. I'm very much looking forward to the maturity of the next release and I feel like what's going to keep the momentum going the best right now is stable releases with fewer bugs. That is more important to me than the new parser.

Thanks for listening,

~ Andy Fillebrown / docEdub

On Tue, Sep 14, 2021 at 1:20 PM Pete Goodeve <pete.goodeve@computer.org> wrote:

A strong +1 on this from me.  Iain has echoed my own opinion far more
clearly than I could!

Thanks!

        -- Pete --

On Tue, Sep 14, 2021 at 07:32:18AM -0700, Iain Duncan wrote:
> Hi Victor and others, of course I'm not a csound dev and nor have I been
> involved for many years (though I'm using it again now), so take what I say
> with a grain of salt. I am, FWIW, a technical due diligence consultant to
> software companies getting major investments or being acquired so talking
> with software companies about their releases cycles, development processes,
> etc, is my day job now, for everything from tiny shops to $1B monsters. And
> an open source author of a much much smaller project, haha. My thoughts
> from the sidelines:
>
> - The new parser sounds like a great step forward, kudos!
> - If there is any risk of the merge of the new parser breaking things in 6,
> when it comes out, because of uncaught backwards incompatibility at this
> point, I think it should not be merged to 6. This is the kind of thing that
> alienates users and creates negative impressions that can be very hard to
> get over later, in my experience.
> - As above for the API. People using the API in apps and frontends expect
> API stability unless there is a major version number change. Breaking that
> expectation can lose you some of the most important users, in my humble
> opinion.
> - The million dollar question: does the csound dev community/system have
> the QA infrastructure/process in place to ensure the above won't be issues?
> Please do not take that as  a value judgement, automating QA is hard work,
> I honestly don't know what the situation is these days though I can see
> it's much more automated than it was 10-15 years ago. But I think if the
> answer is no or unknown, then merging to 6 is rash.
> - Given the above, is there a compelling reason not to maintain a 6 stable
> and 7-alpha version for some period of overlap?  I see this done sometimes
> in both open source and commercial software for this type of situation.
> When a public stable version is maintained and strictly tested, people are
> much more forgiving about the bleeding edge on the next one. The 7-alpha
> does not have to be 7 *as it is planned now*, it could be 6 with the new
> parser and be the merge target for other features for some period (6
> months, a year, whatever). In my experience, and from people I've spoken
> to, maintaining a second release line is actually less work than it sounds
> like it will be, as so much of the work for the first one is reusable. It
> does not have to lead to the dreaded Python 2 to 3 situation if handled
> properly.
> - An advantage of the above is that the new features become something
> people can see. In my impression, a big problem with projects like csound,
> where the system is very complex and most of the devs are juggling the rest
> of their academic duties and so on, is that the development can come across
> to public users as very hidden, or worse, as if it's not going on, just
> because it's not visible to them in the way they are used to from
> constantly releasing reference projects. Whether we agree with it or not,
> visibility of new features moving along is a big part of what potential new
> users look for. (I am guilty of not handling this well myself and have
> resolved to try to fix it for Scheme for Max after 0.3 this month!)
>
> Them's my two cents Canadian, with no expectation that anyone has any
> reason to listen to me. :-)  Now that I am through my conference/thesis
> first paper, I shall be using Csound more and would be happy to help test
> builds.
>
> iain
>
> On Tue, Sep 14, 2021 at 2:57 AM Victor Lazzarini <Victor.Lazzarini@mu.ie>
> wrote:
>
> > yes, we have already done that. But if we take previous version upgrades
> > experiences, we'll probably be breaking stuff left, right and center before
> > we can move forward.
> >
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> >
> > On 14 Sep 2021, at 09:30, Rory Walsh <rorywalsh@ear.ie> wrote:
> >
> > 
> >
> >> The thing is that Cs7 will not be in a working condition for a good
> >> while, whereas 6.17 will be.
> >>
> >
> > I was under the impression that you would simply create a new cs7 branch,
> > merge 6.17 into it and continue from there, which would be the same as
> > continuing in 6.17, but offers a cleaner break?
> >
> >

yes sounds like a good solution, and somehow considering most arguments
from this discussion.
thanks for getting closer to CS7 ---
        joachim


On 15/09/2021 20:02, Victor Lazzarini wrote:
> I think this is a good compromise and I am in favour of it.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 15 Sep 2021, at 16:54, Steven Yi <stevenyi@gmail.com> wrote:
>>
>> 
>> Hi All,
>>
>> I'm happy to see this work making its way into the main development. I
>> think the stability is really important and I think we've discussed
>> this option before but I'd like to propose it again, which is to
>> create a stable branch from develop (csound6) where we can continue on
>> with csound6 maintenance and merge parser3 into develop and make
>> develop the branch for cs7 work.  I think since there's a number of
>> changes for 6.17 already happened, we could look to finish up 6.17
>> soon, then do the csound6 and parser3 merging after that release.
>>
>> One impact this may have though is that anyone using something like
>> homebrew who does builds from HEAD may get CS7 as develop is the
>> default branch.  As there will undoubtedly be some instabilities it
>> may cause some confusion but I imagine we just work through to help
>> downstream maintainers.
>>
>> Steven
>>
>> On Wed, Sep 15, 2021 at 7:42 AM andy fillebrown
>> <andy.fillebrown@gmail.com <mailto:andy.fillebrown@gmail.com>> wrote:
>>
>>
>>     Good points. To be clear, I think you're all doing a great job
>>     with Cabbage and Csound and I'm appreciative of the responsiveness
>>     in fixing bugs. I feel like both Cabbage and Csound are in really
>>     good shape, and while I'm very much looking forward to the new
>>     features in Csound 7, I'm even more looking forward to working
>>     with Csound 6 as-is. Csound 6 is very good software right now.
>>
>>     Thank you,
>>     ~ Andy Fillebrown / docEdub
>>
>>
>>
>>     On Wed, Sep 15, 2021 at 4:11 AM Rory Walsh <rorywalsh@ear.ie
>>     <mailto:rorywalsh@ear.ie>> wrote:
>>
>>         To be fair to you Andy, you really push Csound in ways the
>>         average users can only dream about. However, it's been a while
>>         since you reported any issues with Cabbage. As a member of the
>>         Cabbage forum, you know I tend to deal with issues as soon as
>>         they appear. And in the times you've made PRs I've never had
>>         any issues in merging. I'd be happy if you made more 😀
>>
>>         It looks like you've switched focus to CsoundWASM at the
>>         minute, so maybe you're taking a break from Cabbage. Hopefully
>>         by the time you return it will be better than ever ;)
>>
>>         Your WebXr stuff looks really impressive btw! I'm looking
>>         forward to following your progress there.
>>
>>
>>         On Wed, 15 Sept 2021 at 07:04, Victor Lazzarini
>>         <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>> wrote:
>>
>>             Thanks for this. I understand your point of view, and
>>             there is sense in it.
>>
>>             I just want to point out that, while not denying what you
>>             say, I don't agree that Csound is particularly buggy. In
>>             fact, on the contrary, it is quite mature as a technology.
>>
>>             The bugs you are reporting are to do with the web platform
>>             and that is of course on the edge, particularly as they
>>             have moved to a different compiler and are reworking that
>>             API. I can't comment on Cabbage bugs because that is a
>>             third party project we do not have anything to do with
>>             (apart from supporting), it is not Csound.
>>
>>             It is great that you are supporting that effort, and as
>>             you can see that bit has not yet been released so you are
>>             working with what can best be described as beta or even
>>             possibly alpha code. No wonder you are having second
>>             thoughts about using it, it's not really in production
>>             shape. However, this is not representative of the Csound
>>             code as a whole.
>>
>>             If you look at the Csound issue tracker, you will not see
>>             much action beyond these cutting edge platforms/tech. In
>>             fact, excluding web csound, I don't think there are any
>>             bug tickets currently open (we tend to try and address
>>             these as quickly as possible) and certainly no show
>>             stoppers as far as I can see (if there are I am happy to
>>             be corrected and will address them immediately).
>>
>>             Anyway, thanks again for your comments.
>>
>>             Prof. Victor Lazzarini
>>             Maynooth University
>>             Ireland
>>
>>>             On 15 Sep 2021, at 06:24, andy fillebrown
>>>             <andy.fillebrown@gmail.com
>>>             <mailto:andy.fillebrown@gmail.com>> wrote:
>>>
>>>             
>>>
>>>             Thanks for opening this up for discussion.
>>>
>>>             tldr; I love Csound but I'm tired of running into its
>>>             bugs. I vote for keeping the current parser for 6.17 if
>>>             the new parser can't coexist with it.
>>>
>>>             I very much want to use the new parser features but I do
>>>             not want to risk the stability of 6.17. There are many
>>>             changes in 6.17 that I am waiting for and it would be
>>>             frustrating to me if it brought in new issues due to the
>>>             new parser. I do not want to be stuck on 6.16 until the
>>>             new parser issues are fixed.
>>>
>>>             If there are not enough dev resources to maintain two
>>>             releases then I vote for stability over new parser.
>>>
>>>             Is there no way to put the new parser behind a command
>>>             line argument? Didn't the version 5 to 6 parser change
>>>             work that way? If that's not the case for version 6 to 7
>>>             then I'd rather see it pushed to 7, especially since the
>>>             API would change. Maybe make 7 more of a
>>>             transition/experimental release and move quickly to 8?
>>>             Just a thought
>>>
>>>             Regardless of what is decided I think it's important to
>>>             say that I feel like Csound is gaining a fair amount of
>>>             momentum in the past few years due to the decisions made
>>>             in the past by the lead devs, e.g. the move to Github,
>>>             switching from Scons to CMake, and the relatively smooth
>>>             transition from version 5 to 6. In hindsight these have
>>>             clearly been the right decisions, so I'm not too
>>>             concerned about how the new parser is handled. I trust
>>>             that the devs have the community's best interests in mind.
>>>
>>>             That being said, from my point of view it would be a
>>>             shame to lose the momentum gained from those good past
>>>             decisions by replacing the relatively stable parser with
>>>             an unknown. Csound has a history of being buggy and as an
>>>             artist, my choice to use Csound and Cabbage has been the
>>>             biggest risk in my toolchain due to the number of bugs I
>>>             have encountered. I have had to stop working on my
>>>             project several times this past year to fix issues in
>>>             Cabbage and Csound, and two weeks ago I came very close
>>>             to giving up on using Csound WASM in my WebXR project due
>>>             to show-stopping memory issues. Fortunately, I persisted
>>>             and was able to fix the issues, so I'm in a good place
>>>             now and I'm moving forward on my project nicely. The dev
>>>             fatigue I'm feeling from the Cabbage and Csound bugs is
>>>             real, though. I very much want to just make stuff with
>>>             these awesome tools you all have given us, and I feel
>>>             like version 6 is just now starting to become
>>>             satisfactorily stable enough to do that. I'm very much
>>>             looking forward to the maturity of the next release and I
>>>             feel like what's going to keep the momentum going the
>>>             best right now is stable releases with fewer bugs. That
>>>             is more important to me than the new parser.
>>>
>>>             Thanks for listening,
>>>             ~ Andy Fillebrown / docEdub
>>>
>>>
>>>
>>>             On Tue, Sep 14, 2021 at 1:20 PM Pete Goodeve
>>>             <pete.goodeve@computer.org
>>>             <mailto:pete.goodeve@computer.org>> wrote:
>>>
>>>                 A strong +1 on this from me.  Iain has echoed my own
>>>                 opinion far more
>>>                 clearly than I could!
>>>
>>>                 Thanks!
>>>
>>>                         -- Pete --
>>>
>>>                 On Tue, Sep 14, 2021 at 07:32:18AM -0700, Iain Duncan
>>>                 wrote:
>>>                 > Hi Victor and others, of course I'm not a csound
>>>                 dev and nor have I been
>>>                 > involved for many years (though I'm using it again
>>>                 now), so take what I say
>>>                 > with a grain of salt. I am, FWIW, a technical due
>>>                 diligence consultant to
>>>                 > software companies getting major investments or
>>>                 being acquired so talking
>>>                 > with software companies about their releases
>>>                 cycles, development processes,
>>>                 > etc, is my day job now, for everything from tiny
>>>                 shops to $1B monsters. And
>>>                 > an open source author of a much much smaller
>>>                 project, haha. My thoughts
>>>                 > from the sidelines:
>>>                 >
>>>                 > - The new parser sounds like a great step forward,
>>>                 kudos!
>>>                 > - If there is any risk of the merge of the new
>>>                 parser breaking things in 6,
>>>                 > when it comes out, because of uncaught backwards
>>>                 incompatibility at this
>>>                 > point, I think it should not be merged to 6. This
>>>                 is the kind of thing that
>>>                 > alienates users and creates negative impressions
>>>                 that can be very hard to
>>>                 > get over later, in my experience.
>>>                 > - As above for the API. People using the API in
>>>                 apps and frontends expect
>>>                 > API stability unless there is a major version
>>>                 number change. Breaking that
>>>                 > expectation can lose you some of the most important
>>>                 users, in my humble
>>>                 > opinion.
>>>                 > - The million dollar question: does the csound dev
>>>                 community/system have
>>>                 > the QA infrastructure/process in place to ensure
>>>                 the above won't be issues?
>>>                 > Please do not take that as  a value judgement,
>>>                 automating QA is hard work,
>>>                 > I honestly don't know what the situation is these
>>>                 days though I can see
>>>                 > it's much more automated than it was 10-15 years
>>>                 ago. But I think if the
>>>                 > answer is no or unknown, then merging to 6 is rash.
>>>                 > - Given the above, is there a compelling reason not
>>>                 to maintain a 6 stable
>>>                 > and 7-alpha version for some period of overlap?  I
>>>                 see this done sometimes
>>>                 > in both open source and commercial software for
>>>                 this type of situation.
>>>                 > When a public stable version is maintained and
>>>                 strictly tested, people are
>>>                 > much more forgiving about the bleeding edge on the
>>>                 next one. The 7-alpha
>>>                 > does not have to be 7 *as it is planned now*, it
>>>                 could be 6 with the new
>>>                 > parser and be the merge target for other features
>>>                 for some period (6
>>>                 > months, a year, whatever). In my experience, and
>>>                 from people I've spoken
>>>                 > to, maintaining a second release line is actually
>>>                 less work than it sounds
>>>                 > like it will be, as so much of the work for the
>>>                 first one is reusable. It
>>>                 > does not have to lead to the dreaded Python 2 to 3
>>>                 situation if handled
>>>                 > properly.
>>>                 > - An advantage of the above is that the new
>>>                 features become something
>>>                 > people can see. In my impression, a big problem
>>>                 with projects like csound,
>>>                 > where the system is very complex and most of the
>>>                 devs are juggling the rest
>>>                 > of their academic duties and so on, is that the
>>>                 development can come across
>>>                 > to public users as very hidden, or worse, as if
>>>                 it's not going on, just
>>>                 > because it's not visible to them in the way they
>>>                 are used to from
>>>                 > constantly releasing reference projects. Whether we
>>>                 agree with it or not,
>>>                 > visibility of new features moving along is a big
>>>                 part of what potential new
>>>                 > users look for. (I am guilty of not handling this
>>>                 well myself and have
>>>                 > resolved to try to fix it for Scheme for Max after
>>>                 0.3 this month!)
>>>                 >
>>>                 > Them's my two cents Canadian, with no expectation
>>>                 that anyone has any
>>>                 > reason to listen to me. :-)  Now that I am through
>>>                 my conference/thesis
>>>                 > first paper, I shall be using Csound more and would
>>>                 be happy to help test
>>>                 > builds.
>>>                 >
>>>                 > iain
>>>                 >
>>>                 > On Tue, Sep 14, 2021 at 2:57 AM Victor Lazzarini
>>>                 <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>>
>>>                 > wrote:
>>>                 >
>>>                 > > yes, we have already done that. But if we take
>>>                 previous version upgrades
>>>                 > > experiences, we'll probably be breaking stuff
>>>                 left, right and center before
>>>                 > > we can move forward.
>>>                 > >
>>>                 > > Prof. Victor Lazzarini
>>>                 > > Maynooth University
>>>                 > > Ireland
>>>                 > >
>>>                 > > On 14 Sep 2021, at 09:30, Rory Walsh
>>>                 <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>> wrote:
>>>                 > >
>>>                 > > 
>>>                 > >
>>>                 > >> The thing is that Cs7 will not be in a working
>>>                 condition for a good
>>>                 > >> while, whereas 6.17 will be.
>>>                 > >>
>>>                 > >
>>>                 > > I was under the impression that you would simply
>>>                 create a new cs7 branch,
>>>                 > > merge 6.17 into it and continue from there, which
>>>                 would be the same as
>>>                 > > continuing in 6.17, but offers a cleaner break?
>>>                 > >
>>>                 > >
>>>

I don't think it will. We use master as our stable released code and develop as our ordinary development work, and feature/* as side feature development.

The proposal is to continue like this bumping the version to 7.0, but keep a maintenance 6.x branch from which we will do bugfix releases (which become master) until 7.0 is finally released.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 15 Sep 2021, at 20:15, Iain Duncan <iainduncanlists@gmail.com> wrote:



If I may, I would like to suggest one thing from the side lines. I would recommend that the long lived development branch in which the parser work is happening *not* be main/master/trunk.   To people coming to csound from other programming areas, it creates a strongly negative impression if trunk doesn't always build and work, as this is the normal practice in commercial dev these days and to many, is a bit of a de facto sniff test for how development is conducted. The approach that will not scare these people off would be to have  6.x releases be tags from trunk, and the long lived develop branch is separate but can rebase 6.xx releases into itself to keep current with minor mainteance work from the 6.x mainline. (Develop can even have sub feature branches cut off of itself). This will ensure that trunk always builds with tests passing, and clearly indicates that develop is a moving target that is not expected or intended to be releasable at any point. 

hth!

iain

 

On Wed, Sep 15, 2021 at 11:58 AM joachim heintz <jh@joachimheintz.de> wrote:

yes sounds like a good solution, and somehow considering most arguments
from this discussion.
thanks for getting closer to CS7 ---
        joachim


On 15/09/2021 20:02, Victor Lazzarini wrote:
> I think this is a good compromise and I am in favour of it.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 15 Sep 2021, at 16:54, Steven Yi <stevenyi@gmail.com> wrote:
>>
>> 
>> Hi All,
>>
>> I'm happy to see this work making its way into the main development. I
>> think the stability is really important and I think we've discussed
>> this option before but I'd like to propose it again, which is to
>> create a stable branch from develop (csound6) where we can continue on
>> with csound6 maintenance and merge parser3 into develop and make
>> develop the branch for cs7 work.  I think since there's a number of
>> changes for 6.17 already happened, we could look to finish up 6.17
>> soon, then do the csound6 and parser3 merging after that release.
>>
>> One impact this may have though is that anyone using something like
>> homebrew who does builds from HEAD may get CS7 as develop is the
>> default branch.  As there will undoubtedly be some instabilities it
>> may cause some confusion but I imagine we just work through to help
>> downstream maintainers.
>>
>> Steven
>>
>> On Wed, Sep 15, 2021 at 7:42 AM andy fillebrown
>> <andy.fillebrown@gmail.com <mailto:andy.fillebrown@gmail.com>> wrote:
>>
>>
>>     Good points. To be clear, I think you're all doing a great job
>>     with Cabbage and Csound and I'm appreciative of the responsiveness
>>     in fixing bugs. I feel like both Cabbage and Csound are in really
>>     good shape, and while I'm very much looking forward to the new
>>     features in Csound 7, I'm even more looking forward to working
>>     with Csound 6 as-is. Csound 6 is very good software right now.
>>
>>     Thank you,
>>     ~ Andy Fillebrown / docEdub
>>
>>
>>
>>     On Wed, Sep 15, 2021 at 4:11 AM Rory Walsh <rorywalsh@ear.ie
>>     <mailto:rorywalsh@ear.ie>> wrote:
>>
>>         To be fair to you Andy, you really push Csound in ways the
>>         average users can only dream about. However, it's been a while
>>         since you reported any issues with Cabbage. As a member of the
>>         Cabbage forum, you know I tend to deal with issues as soon as
>>         they appear. And in the times you've made PRs I've never had
>>         any issues in merging. I'd be happy if you made more 😀
>>
>>         It looks like you've switched focus to CsoundWASM at the
>>         minute, so maybe you're taking a break from Cabbage. Hopefully
>>         by the time you return it will be better than ever ;)
>>
>>         Your WebXr stuff looks really impressive btw! I'm looking
>>         forward to following your progress there.
>>
>>
>>         On Wed, 15 Sept 2021 at 07:04, Victor Lazzarini
>>         <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>> wrote:
>>
>>             Thanks for this. I understand your point of view, and
>>             there is sense in it.
>>
>>             I just want to point out that, while not denying what you
>>             say, I don't agree that Csound is particularly buggy. In
>>             fact, on the contrary, it is quite mature as a technology.
>>
>>             The bugs you are reporting are to do with the web platform
>>             and that is of course on the edge, particularly as they
>>             have moved to a different compiler and are reworking that
>>             API. I can't comment on Cabbage bugs because that is a
>>             third party project we do not have anything to do with
>>             (apart from supporting), it is not Csound.
>>
>>             It is great that you are supporting that effort, and as
>>             you can see that bit has not yet been released so you are
>>             working with what can best be described as beta or even
>>             possibly alpha code. No wonder you are having second
>>             thoughts about using it, it's not really in production
>>             shape. However, this is not representative of the Csound
>>             code as a whole.
>>
>>             If you look at the Csound issue tracker, you will not see
>>             much action beyond these cutting edge platforms/tech. In
>>             fact, excluding web csound, I don't think there are any
>>             bug tickets currently open (we tend to try and address
>>             these as quickly as possible) and certainly no show
>>             stoppers as far as I can see (if there are I am happy to
>>             be corrected and will address them immediately).
>>
>>             Anyway, thanks again for your comments.
>>
>>             Prof. Victor Lazzarini
>>             Maynooth University
>>             Ireland
>>
>>>             On 15 Sep 2021, at 06:24, andy fillebrown
>>>             <andy.fillebrown@gmail.com
>>>             <mailto:andy.fillebrown@gmail.com>> wrote:
>>>
>>>             
>>>
>>>             Thanks for opening this up for discussion.
>>>
>>>             tldr; I love Csound but I'm tired of running into its
>>>             bugs. I vote for keeping the current parser for 6.17 if
>>>             the new parser can't coexist with it.
>>>
>>>             I very much want to use the new parser features but I do
>>>             not want to risk the stability of 6.17. There are many
>>>             changes in 6.17 that I am waiting for and it would be
>>>             frustrating to me if it brought in new issues due to the
>>>             new parser. I do not want to be stuck on 6.16 until the
>>>             new parser issues are fixed.
>>>
>>>             If there are not enough dev resources to maintain two
>>>             releases then I vote for stability over new parser.
>>>
>>>             Is there no way to put the new parser behind a command
>>>             line argument? Didn't the version 5 to 6 parser change
>>>             work that way? If that's not the case for version 6 to 7
>>>             then I'd rather see it pushed to 7, especially since the
>>>             API would change. Maybe make 7 more of a
>>>             transition/experimental release and move quickly to 8?
>>>             Just a thought
>>>
>>>             Regardless of what is decided I think it's important to
>>>             say that I feel like Csound is gaining a fair amount of
>>>             momentum in the past few years due to the decisions made
>>>             in the past by the lead devs, e.g. the move to Github,
>>>             switching from Scons to CMake, and the relatively smooth
>>>             transition from version 5 to 6. In hindsight these have
>>>             clearly been the right decisions, so I'm not too
>>>             concerned about how the new parser is handled. I trust
>>>             that the devs have the community's best interests in mind.
>>>
>>>             That being said, from my point of view it would be a
>>>             shame to lose the momentum gained from those good past
>>>             decisions by replacing the relatively stable parser with
>>>             an unknown. Csound has a history of being buggy and as an
>>>             artist, my choice to use Csound and Cabbage has been the
>>>             biggest risk in my toolchain due to the number of bugs I
>>>             have encountered. I have had to stop working on my
>>>             project several times this past year to fix issues in
>>>             Cabbage and Csound, and two weeks ago I came very close
>>>             to giving up on using Csound WASM in my WebXR project due
>>>             to show-stopping memory issues. Fortunately, I persisted
>>>             and was able to fix the issues, so I'm in a good place
>>>             now and I'm moving forward on my project nicely. The dev
>>>             fatigue I'm feeling from the Cabbage and Csound bugs is
>>>             real, though. I very much want to just make stuff with
>>>             these awesome tools you all have given us, and I feel
>>>             like version 6 is just now starting to become
>>>             satisfactorily stable enough to do that. I'm very much
>>>             looking forward to the maturity of the next release and I
>>>             feel like what's going to keep the momentum going the
>>>             best right now is stable releases with fewer bugs. That
>>>             is more important to me than the new parser.
>>>
>>>             Thanks for listening,
>>>             ~ Andy Fillebrown / docEdub
>>>
>>>
>>>
>>>             On Tue, Sep 14, 2021 at 1:20 PM Pete Goodeve
>>>             <pete.goodeve@computer.org
>>>             <mailto:pete.goodeve@computer.org>> wrote:
>>>
>>>                 A strong +1 on this from me.  Iain has echoed my own
>>>                 opinion far more
>>>                 clearly than I could!
>>>
>>>                 Thanks!
>>>
>>>                         -- Pete --
>>>
>>>                 On Tue, Sep 14, 2021 at 07:32:18AM -0700, Iain Duncan
>>>                 wrote:
>>>                 > Hi Victor and others, of course I'm not a csound
>>>                 dev and nor have I been
>>>                 > involved for many years (though I'm using it again
>>>                 now), so take what I say
>>>                 > with a grain of salt. I am, FWIW, a technical due
>>>                 diligence consultant to
>>>                 > software companies getting major investments or
>>>                 being acquired so talking
>>>                 > with software companies about their releases
>>>                 cycles, development processes,
>>>                 > etc, is my day job now, for everything from tiny
>>>                 shops to $1B monsters. And
>>>                 > an open source author of a much much smaller
>>>                 project, haha. My thoughts
>>>                 > from the sidelines:
>>>                 >
>>>                 > - The new parser sounds like a great step forward,
>>>                 kudos!
>>>                 > - If there is any risk of the merge of the new
>>>                 parser breaking things in 6,
>>>                 > when it comes out, because of uncaught backwards
>>>                 incompatibility at this
>>>                 > point, I think it should not be merged to 6. This
>>>                 is the kind of thing that
>>>                 > alienates users and creates negative impressions
>>>                 that can be very hard to
>>>                 > get over later, in my experience.
>>>                 > - As above for the API. People using the API in
>>>                 apps and frontends expect
>>>                 > API stability unless there is a major version
>>>                 number change. Breaking that
>>>                 > expectation can lose you some of the most important
>>>                 users, in my humble
>>>                 > opinion.
>>>                 > - The million dollar question: does the csound dev
>>>                 community/system have
>>>                 > the QA infrastructure/process in place to ensure
>>>                 the above won't be issues?
>>>                 > Please do not take that as  a value judgement,
>>>                 automating QA is hard work,
>>>                 > I honestly don't know what the situation is these
>>>                 days though I can see
>>>                 > it's much more automated than it was 10-15 years
>>>                 ago. But I think if the
>>>                 > answer is no or unknown, then merging to 6 is rash.
>>>                 > - Given the above, is there a compelling reason not
>>>                 to maintain a 6 stable
>>>                 > and 7-alpha version for some period of overlap?  I
>>>                 see this done sometimes
>>>                 > in both open source and commercial software for
>>>                 this type of situation.
>>>                 > When a public stable version is maintained and
>>>                 strictly tested, people are
>>>                 > much more forgiving about the bleeding edge on the
>>>                 next one. The 7-alpha
>>>                 > does not have to be 7 *as it is planned now*, it
>>>                 could be 6 with the new
>>>                 > parser and be the merge target for other features
>>>                 for some period (6
>>>                 > months, a year, whatever). In my experience, and
>>>                 from people I've spoken
>>>                 > to, maintaining a second release line is actually
>>>                 less work than it sounds
>>>                 > like it will be, as so much of the work for the
>>>                 first one is reusable. It
>>>                 > does not have to lead to the dreaded Python 2 to 3
>>>                 situation if handled
>>>                 > properly.
>>>                 > - An advantage of the above is that the new
>>>                 features become something
>>>                 > people can see. In my impression, a big problem
>>>                 with projects like csound,
>>>                 > where the system is very complex and most of the
>>>                 devs are juggling the rest
>>>                 > of their academic duties and so on, is that the
>>>                 development can come across
>>>                 > to public users as very hidden, or worse, as if
>>>                 it's not going on, just
>>>                 > because it's not visible to them in the way they
>>>                 are used to from
>>>                 > constantly releasing reference projects. Whether we
>>>                 agree with it or not,
>>>                 > visibility of new features moving along is a big
>>>                 part of what potential new
>>>                 > users look for. (I am guilty of not handling this
>>>                 well myself and have
>>>                 > resolved to try to fix it for Scheme for Max after
>>>                 0.3 this month!)
>>>                 >
>>>                 > Them's my two cents Canadian, with no expectation
>>>                 that anyone has any
>>>                 > reason to listen to me. :-)  Now that I am through
>>>                 my conference/thesis
>>>                 > first paper, I shall be using Csound more and would
>>>                 be happy to help test
>>>                 > builds.
>>>                 >
>>>                 > iain
>>>                 >
>>>                 > On Tue, Sep 14, 2021 at 2:57 AM Victor Lazzarini
>>>                 <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>>
>>>                 > wrote:
>>>                 >
>>>                 > > yes, we have already done that. But if we take
>>>                 previous version upgrades
>>>                 > > experiences, we'll probably be breaking stuff
>>>                 left, right and center before
>>>                 > > we can move forward.
>>>                 > >
>>>                 > > Prof. Victor Lazzarini
>>>                 > > Maynooth University
>>>                 > > Ireland
>>>                 > >
>>>                 > > On 14 Sep 2021, at 09:30, Rory Walsh
>>>                 <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>> wrote:
>>>                 > >
>>>                 > > 
>>>                 > >
>>>                 > >> The thing is that Cs7 will not be in a working
>>>                 condition for a good
>>>                 > >> while, whereas 6.17 will be.
>>>                 > >>
>>>                 > >
>>>                 > > I was under the impression that you would simply
>>>                 create a new cs7 branch,
>>>                 > > merge 6.17 into it and continue from there, which
>>>                 would be the same as
>>>                 > > continuing in 6.17, but offers a cleaner break?
>>>                 > >
>>>                 > >
>>>

But there's also an important point associated with your question. We have used develop as our default git hub branch for years.  The question is whether we should switch it back to master (and protect against accidental writing maybe?)

Prof. Victor Lazzarini

Maynooth University

Ireland

On 15 Sep 2021, at 20:35, Iain Duncan <iainduncanlists@gmail.com> wrote:



Thanks for clarifying that Victor, good to know. :-)

iain

On Wed, Sep 15, 2021 at 12:29 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

I don't think it will. We use master as our stable released code and develop as our ordinary development work, and feature/* as side feature development.

The proposal is to continue like this bumping the version to 7.0, but keep a maintenance 6.x branch from which we will do bugfix releases (which become master) until 7.0 is finally released.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 15 Sep 2021, at 20:15, Iain Duncan <iainduncanlists@gmail.com> wrote:



If I may, I would like to suggest one thing from the side lines. I would recommend that the long lived development branch in which the parser work is happening *not* be main/master/trunk.   To people coming to csound from other programming areas, it creates a strongly negative impression if trunk doesn't always build and work, as this is the normal practice in commercial dev these days and to many, is a bit of a de facto sniff test for how development is conducted. The approach that will not scare these people off would be to have  6.x releases be tags from trunk, and the long lived develop branch is separate but can rebase 6.xx releases into itself to keep current with minor mainteance work from the 6.x mainline. (Develop can even have sub feature branches cut off of itself). This will ensure that trunk always builds with tests passing, and clearly indicates that develop is a moving target that is not expected or intended to be releasable at any point. 

hth!

iain

 

On Wed, Sep 15, 2021 at 11:58 AM joachim heintz <jh@joachimheintz.de> wrote:

yes sounds like a good solution, and somehow considering most arguments
from this discussion.
thanks for getting closer to CS7 ---
        joachim


On 15/09/2021 20:02, Victor Lazzarini wrote:
> I think this is a good compromise and I am in favour of it.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 15 Sep 2021, at 16:54, Steven Yi <stevenyi@gmail.com> wrote:
>>
>> 
>> Hi All,
>>
>> I'm happy to see this work making its way into the main development. I
>> think the stability is really important and I think we've discussed
>> this option before but I'd like to propose it again, which is to
>> create a stable branch from develop (csound6) where we can continue on
>> with csound6 maintenance and merge parser3 into develop and make
>> develop the branch for cs7 work.  I think since there's a number of
>> changes for 6.17 already happened, we could look to finish up 6.17
>> soon, then do the csound6 and parser3 merging after that release.
>>
>> One impact this may have though is that anyone using something like
>> homebrew who does builds from HEAD may get CS7 as develop is the
>> default branch.  As there will undoubtedly be some instabilities it
>> may cause some confusion but I imagine we just work through to help
>> downstream maintainers.
>>
>> Steven
>>
>> On Wed, Sep 15, 2021 at 7:42 AM andy fillebrown
>> <andy.fillebrown@gmail.com <mailto:andy.fillebrown@gmail.com>> wrote:
>>
>>
>>     Good points. To be clear, I think you're all doing a great job
>>     with Cabbage and Csound and I'm appreciative of the responsiveness
>>     in fixing bugs. I feel like both Cabbage and Csound are in really
>>     good shape, and while I'm very much looking forward to the new
>>     features in Csound 7, I'm even more looking forward to working
>>     with Csound 6 as-is. Csound 6 is very good software right now.
>>
>>     Thank you,
>>     ~ Andy Fillebrown / docEdub
>>
>>
>>
>>     On Wed, Sep 15, 2021 at 4:11 AM Rory Walsh <rorywalsh@ear.ie
>>     <mailto:rorywalsh@ear.ie>> wrote:
>>
>>         To be fair to you Andy, you really push Csound in ways the
>>         average users can only dream about. However, it's been a while
>>         since you reported any issues with Cabbage. As a member of the
>>         Cabbage forum, you know I tend to deal with issues as soon as
>>         they appear. And in the times you've made PRs I've never had
>>         any issues in merging. I'd be happy if you made more 😀
>>
>>         It looks like you've switched focus to CsoundWASM at the
>>         minute, so maybe you're taking a break from Cabbage. Hopefully
>>         by the time you return it will be better than ever ;)
>>
>>         Your WebXr stuff looks really impressive btw! I'm looking
>>         forward to following your progress there.
>>
>>
>>         On Wed, 15 Sept 2021 at 07:04, Victor Lazzarini
>>         <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>> wrote:
>>
>>             Thanks for this. I understand your point of view, and
>>             there is sense in it.
>>
>>             I just want to point out that, while not denying what you
>>             say, I don't agree that Csound is particularly buggy. In
>>             fact, on the contrary, it is quite mature as a technology.
>>
>>             The bugs you are reporting are to do with the web platform
>>             and that is of course on the edge, particularly as they
>>             have moved to a different compiler and are reworking that
>>             API. I can't comment on Cabbage bugs because that is a
>>             third party project we do not have anything to do with
>>             (apart from supporting), it is not Csound.
>>
>>             It is great that you are supporting that effort, and as
>>             you can see that bit has not yet been released so you are
>>             working with what can best be described as beta or even
>>             possibly alpha code. No wonder you are having second
>>             thoughts about using it, it's not really in production
>>             shape. However, this is not representative of the Csound
>>             code as a whole.
>>
>>             If you look at the Csound issue tracker, you will not see
>>             much action beyond these cutting edge platforms/tech. In
>>             fact, excluding web csound, I don't think there are any
>>             bug tickets currently open (we tend to try and address
>>             these as quickly as possible) and certainly no show
>>             stoppers as far as I can see (if there are I am happy to
>>             be corrected and will address them immediately).
>>
>>             Anyway, thanks again for your comments.
>>
>>             Prof. Victor Lazzarini
>>             Maynooth University
>>             Ireland
>>
>>>             On 15 Sep 2021, at 06:24, andy fillebrown
>>>             <andy.fillebrown@gmail.com
>>>             <mailto:andy.fillebrown@gmail.com>> wrote:
>>>
>>>             
>>>
>>>             Thanks for opening this up for discussion.
>>>
>>>             tldr; I love Csound but I'm tired of running into its
>>>             bugs. I vote for keeping the current parser for 6.17 if
>>>             the new parser can't coexist with it.
>>>
>>>             I very much want to use the new parser features but I do
>>>             not want to risk the stability of 6.17. There are many
>>>             changes in 6.17 that I am waiting for and it would be
>>>             frustrating to me if it brought in new issues due to the
>>>             new parser. I do not want to be stuck on 6.16 until the
>>>             new parser issues are fixed.
>>>
>>>             If there are not enough dev resources to maintain two
>>>             releases then I vote for stability over new parser.
>>>
>>>             Is there no way to put the new parser behind a command
>>>             line argument? Didn't the version 5 to 6 parser change
>>>             work that way? If that's not the case for version 6 to 7
>>>             then I'd rather see it pushed to 7, especially since the
>>>             API would change. Maybe make 7 more of a
>>>             transition/experimental release and move quickly to 8?
>>>             Just a thought
>>>
>>>             Regardless of what is decided I think it's important to
>>>             say that I feel like Csound is gaining a fair amount of
>>>             momentum in the past few years due to the decisions made
>>>             in the past by the lead devs, e.g. the move to Github,
>>>             switching from Scons to CMake, and the relatively smooth
>>>             transition from version 5 to 6. In hindsight these have
>>>             clearly been the right decisions, so I'm not too
>>>             concerned about how the new parser is handled. I trust
>>>             that the devs have the community's best interests in mind.
>>>
>>>             That being said, from my point of view it would be a
>>>             shame to lose the momentum gained from those good past
>>>             decisions by replacing the relatively stable parser with
>>>             an unknown. Csound has a history of being buggy and as an
>>>             artist, my choice to use Csound and Cabbage has been the
>>>             biggest risk in my toolchain due to the number of bugs I
>>>             have encountered. I have had to stop working on my
>>>             project several times this past year to fix issues in
>>>             Cabbage and Csound, and two weeks ago I came very close
>>>             to giving up on using Csound WASM in my WebXR project due
>>>             to show-stopping memory issues. Fortunately, I persisted
>>>             and was able to fix the issues, so I'm in a good place
>>>             now and I'm moving forward on my project nicely. The dev
>>>             fatigue I'm feeling from the Cabbage and Csound bugs is
>>>             real, though. I very much want to just make stuff with
>>>             these awesome tools you all have given us, and I feel
>>>             like version 6 is just now starting to become
>>>             satisfactorily stable enough to do that. I'm very much
>>>             looking forward to the maturity of the next release and I
>>>             feel like what's going to keep the momentum going the
>>>             best right now is stable releases with fewer bugs. That
>>>             is more important to me than the new parser.
>>>
>>>             Thanks for listening,
>>>             ~ Andy Fillebrown / docEdub
>>>
>>>
>>>
>>>             On Tue, Sep 14, 2021 at 1:20 PM Pete Goodeve
>>>             <pete.goodeve@computer.org
>>>             <mailto:pete.goodeve@computer.org>> wrote:
>>>
>>>                 A strong +1 on this from me.  Iain has echoed my own
>>>                 opinion far more
>>>                 clearly than I could!
>>>
>>>                 Thanks!
>>>
>>>                         -- Pete --
>>>
>>>                 On Tue, Sep 14, 2021 at 07:32:18AM -0700, Iain Duncan
>>>                 wrote:
>>>                 > Hi Victor and others, of course I'm not a csound
>>>                 dev and nor have I been
>>>                 > involved for many years (though I'm using it again
>>>                 now), so take what I say
>>>                 > with a grain of salt. I am, FWIW, a technical due
>>>                 diligence consultant to
>>>                 > software companies getting major investments or
>>>                 being acquired so talking
>>>                 > with software companies about their releases
>>>                 cycles, development processes,
>>>                 > etc, is my day job now, for everything from tiny
>>>                 shops to $1B monsters. And
>>>                 > an open source author of a much much smaller
>>>                 project, haha. My thoughts
>>>                 > from the sidelines:
>>>                 >
>>>                 > - The new parser sounds like a great step forward,
>>>                 kudos!
>>>                 > - If there is any risk of the merge of the new
>>>                 parser breaking things in 6,
>>>                 > when it comes out, because of uncaught backwards
>>>                 incompatibility at this
>>>                 > point, I think it should not be merged to 6. This
>>>                 is the kind of thing that
>>>                 > alienates users and creates negative impressions
>>>                 that can be very hard to
>>>                 > get over later, in my experience.
>>>                 > - As above for the API. People using the API in
>>>                 apps and frontends expect
>>>                 > API stability unless there is a major version
>>>                 number change. Breaking that
>>>                 > expectation can lose you some of the most important
>>>                 users, in my humble
>>>                 > opinion.
>>>                 > - The million dollar question: does the csound dev
>>>                 community/system have
>>>                 > the QA infrastructure/process in place to ensure
>>>                 the above won't be issues?
>>>                 > Please do not take that as  a value judgement,
>>>                 automating QA is hard work,
>>>                 > I honestly don't know what the situation is these
>>>                 days though I can see
>>>                 > it's much more automated than it was 10-15 years
>>>                 ago. But I think if the
>>>                 > answer is no or unknown, then merging to 6 is rash.
>>>                 > - Given the above, is there a compelling reason not
>>>                 to maintain a 6 stable
>>>                 > and 7-alpha version for some period of overlap?  I
>>>                 see this done sometimes
>>>                 > in both open source and commercial software for
>>>                 this type of situation.
>>>                 > When a public stable version is maintained and
>>>                 strictly tested, people are
>>>                 > much more forgiving about the bleeding edge on the
>>>                 next one. The 7-alpha
>>>                 > does not have to be 7 *as it is planned now*, it
>>>                 could be 6 with the new
>>>                 > parser and be the merge target for other features
>>>                 for some period (6
>>>                 > months, a year, whatever). In my experience, and
>>>                 from people I've spoken
>>>                 > to, maintaining a second release line is actually
>>>                 less work than it sounds
>>>                 > like it will be, as so much of the work for the
>>>                 first one is reusable. It
>>>                 > does not have to lead to the dreaded Python 2 to 3
>>>                 situation if handled
>>>                 > properly.
>>>                 > - An advantage of the above is that the new
>>>                 features become something
>>>                 > people can see. In my impression, a big problem
>>>                 with projects like csound,
>>>                 > where the system is very complex and most of the
>>>                 devs are juggling the rest
>>>                 > of their academic duties and so on, is that the
>>>                 development can come across
>>>                 > to public users as very hidden, or worse, as if
>>>                 it's not going on, just
>>>                 > because it's not visible to them in the way they
>>>                 are used to from
>>>                 > constantly releasing reference projects. Whether we
>>>                 agree with it or not,
>>>                 > visibility of new features moving along is a big
>>>                 part of what potential new
>>>                 > users look for. (I am guilty of not handling this
>>>                 well myself and have
>>>                 > resolved to try to fix it for Scheme for Max after
>>>                 0.3 this month!)
>>>                 >
>>>                 > Them's my two cents Canadian, with no expectation
>>>                 that anyone has any
>>>                 > reason to listen to me. :-)  Now that I am through
>>>                 my conference/thesis
>>>                 > first paper, I shall be using Csound more and would
>>>                 be happy to help test
>>>                 > builds.
>>>                 >
>>>                 > iain
>>>                 >
>>>                 > On Tue, Sep 14, 2021 at 2:57 AM Victor Lazzarini
>>>                 <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>>
>>>                 > wrote:
>>>                 >
>>>                 > > yes, we have already done that. But if we take
>>>                 previous version upgrades
>>>                 > > experiences, we'll probably be breaking stuff
>>>                 left, right and center before
>>>                 > > we can move forward.
>>>                 > >
>>>                 > > Prof. Victor Lazzarini
>>>                 > > Maynooth University
>>>                 > > Ireland
>>>                 > >
>>>                 > > On 14 Sep 2021, at 09:30, Rory Walsh
>>>                 <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>> wrote:
>>>                 > >
>>>                 > > 
>>>                 > >
>>>                 > >> The thing is that Cs7 will not be in a working
>>>                 condition for a good
>>>                 > >> while, whereas 6.17 will be.
>>>                 > >>
>>>                 > >
>>>                 > > I was under the impression that you would simply
>>>                 create a new cs7 branch,
>>>                 > > merge 6.17 into it and continue from there, which
>>>                 would be the same as
>>>                 > > continuing in 6.17, but offers a cleaner break?
>>>                 > >
>>>                 > >
>>>

This thread prompted me to do some google hunting on what the wider audio world thinks of Csound these days, and one thing that did come up was that Csound's rock-solid backwards compatibility is a real selling point, compared to, for example, SC where people have become frustrated with having to recode their work on new releases. I bring this up just to table that, if this is one of the major selling points, it is probably even more important to ensure continued stability.

It's certainly one of the attractions for me. I'm getting back into it because it's great for controlling with Scheme in Max, and it's great for controlling my modular. Knowing that the same tools I spent years learning, over 20 years ago, will "just work" is a major, major selling point to me. Like many people who cut their professional teeth in the web dev world, I'm just totally burnt out on unnecessary tool churn. 

HTH,

iain

On Wed, Sep 15, 2021 at 4:42 AM andy fillebrown <andy.fillebrown@gmail.com> wrote:

Good points. To be clear, I think you're all doing a great job with Cabbage and Csound and I'm appreciative of the responsiveness in fixing bugs. I feel like both Cabbage and Csound are in really good shape, and while I'm very much looking forward to the new features in Csound 7, I'm even more looking forward to working with Csound 6 as-is. Csound 6 is very good software right now.

Thank you,

~ Andy Fillebrown / docEdub

On Wed, Sep 15, 2021 at 4:11 AM Rory Walsh <rorywalsh@ear.ie> wrote:

To be fair to you Andy, you really push Csound in ways the average users can only dream about. However, it's been a while since you reported any issues with Cabbage. As a member of the Cabbage forum, you know I tend to deal with issues as soon as they appear. And in the times you've made PRs I've never had any issues in merging. I'd be happy if you made more 😀  

It looks like you've switched focus to CsoundWASM at the minute, so maybe you're taking a break from Cabbage. Hopefully by the time you return it will be better than ever ;) 

Your WebXr stuff looks really impressive btw! I'm looking forward to following your progress there. 

On Wed, 15 Sept 2021 at 07:04, Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

Thanks for this. I understand your point of view, and there is sense in it.

I just want to point out that, while not denying what you say, I don't agree that Csound is particularly buggy. In fact, on the contrary, it is quite mature as a technology.

The bugs you are reporting are to do with the web platform and that is of course on the edge, particularly as they have moved to a different compiler and are reworking that API. I can't comment on Cabbage bugs because that is a third party project we do not have anything to do with (apart from supporting), it is not Csound. 

It is great that you are supporting that effort, and as you can see that bit has not yet been released so you are working with what can best be described as beta or even possibly alpha code. No wonder you are having second thoughts about using it, it's not really in production shape. However, this is not representative of the Csound code as a whole.

If you look at the Csound issue tracker, you will not see much action beyond these cutting edge platforms/tech. In fact, excluding web csound, I don't think there are any bug tickets currently open (we tend to try and address these as quickly as possible) and certainly no show stoppers as far as I can see (if there are I am happy to be corrected and will address them immediately).

Anyway, thanks again for your comments.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 15 Sep 2021, at 06:24, andy fillebrown <andy.fillebrown@gmail.com> wrote:



Thanks for opening this up for discussion.

tldr; I love Csound but I'm tired of running into its bugs. I vote for keeping the current parser for 6.17 if the new parser can't coexist with it.

I very much want to use the new parser features but I do not want to risk the stability of 6.17. There are many changes in 6.17 that I am waiting for and it would be frustrating to me if it brought in new issues due to the new parser. I do not want to be stuck on 6.16 until the new parser issues are fixed.

If there are not enough dev resources to maintain two releases then I vote for stability over new parser.

Is there no way to put the new parser behind a command line argument? Didn't the version 5 to 6 parser change work that way? If that's not the case for version 6 to 7 then I'd rather see it pushed to 7, especially since the API would change. Maybe make 7 more of a transition/experimental release and move quickly to 8? Just a thought

Regardless of what is decided I think it's important to say that I feel like Csound is gaining a fair amount of momentum in the past few years due to the decisions made in the past by the lead devs, e.g. the move to Github, switching from Scons to CMake, and the relatively smooth transition from version 5 to 6. In hindsight these have clearly been the right decisions, so I'm not too concerned about how the new parser is handled. I trust that the devs have the community's best interests in mind.

That being said, from my point of view it would be a shame to lose the momentum gained from those good past decisions by replacing the relatively stable parser with an unknown. Csound has a history of being buggy and as an artist, my choice to use Csound and Cabbage has been the biggest risk in my toolchain due to the number of bugs I have encountered. I have had to stop working on my project several times this past year to fix issues in Cabbage and Csound, and two weeks ago I came very close to giving up on using Csound WASM in my WebXR project due to show-stopping memory issues. Fortunately, I persisted and was able to fix the issues, so I'm in a good place now and I'm moving forward on my project nicely. The dev fatigue I'm feeling from the Cabbage and Csound bugs is real, though. I very much want to just make stuff with these awesome tools you all have given us, and I feel like version 6 is just now starting to become satisfactorily stable enough to do that. I'm very much looking forward to the maturity of the next release and I feel like what's going to keep the momentum going the best right now is stable releases with fewer bugs. That is more important to me than the new parser.

Thanks for listening,

~ Andy Fillebrown / docEdub

On Tue, Sep 14, 2021 at 1:20 PM Pete Goodeve <pete.goodeve@computer.org> wrote:

A strong +1 on this from me.  Iain has echoed my own opinion far more
clearly than I could!

Thanks!

        -- Pete --

On Tue, Sep 14, 2021 at 07:32:18AM -0700, Iain Duncan wrote:
> Hi Victor and others, of course I'm not a csound dev and nor have I been
> involved for many years (though I'm using it again now), so take what I say
> with a grain of salt. I am, FWIW, a technical due diligence consultant to
> software companies getting major investments or being acquired so talking
> with software companies about their releases cycles, development processes,
> etc, is my day job now, for everything from tiny shops to $1B monsters. And
> an open source author of a much much smaller project, haha. My thoughts
> from the sidelines:
>
> - The new parser sounds like a great step forward, kudos!
> - If there is any risk of the merge of the new parser breaking things in 6,
> when it comes out, because of uncaught backwards incompatibility at this
> point, I think it should not be merged to 6. This is the kind of thing that
> alienates users and creates negative impressions that can be very hard to
> get over later, in my experience.
> - As above for the API. People using the API in apps and frontends expect
> API stability unless there is a major version number change. Breaking that
> expectation can lose you some of the most important users, in my humble
> opinion.
> - The million dollar question: does the csound dev community/system have
> the QA infrastructure/process in place to ensure the above won't be issues?
> Please do not take that as  a value judgement, automating QA is hard work,
> I honestly don't know what the situation is these days though I can see
> it's much more automated than it was 10-15 years ago. But I think if the
> answer is no or unknown, then merging to 6 is rash.
> - Given the above, is there a compelling reason not to maintain a 6 stable
> and 7-alpha version for some period of overlap?  I see this done sometimes
> in both open source and commercial software for this type of situation.
> When a public stable version is maintained and strictly tested, people are
> much more forgiving about the bleeding edge on the next one. The 7-alpha
> does not have to be 7 *as it is planned now*, it could be 6 with the new
> parser and be the merge target for other features for some period (6
> months, a year, whatever). In my experience, and from people I've spoken
> to, maintaining a second release line is actually less work than it sounds
> like it will be, as so much of the work for the first one is reusable. It
> does not have to lead to the dreaded Python 2 to 3 situation if handled
> properly.
> - An advantage of the above is that the new features become something
> people can see. In my impression, a big problem with projects like csound,
> where the system is very complex and most of the devs are juggling the rest
> of their academic duties and so on, is that the development can come across
> to public users as very hidden, or worse, as if it's not going on, just
> because it's not visible to them in the way they are used to from
> constantly releasing reference projects. Whether we agree with it or not,
> visibility of new features moving along is a big part of what potential new
> users look for. (I am guilty of not handling this well myself and have
> resolved to try to fix it for Scheme for Max after 0.3 this month!)
>
> Them's my two cents Canadian, with no expectation that anyone has any
> reason to listen to me. :-)  Now that I am through my conference/thesis
> first paper, I shall be using Csound more and would be happy to help test
> builds.
>
> iain
>
> On Tue, Sep 14, 2021 at 2:57 AM Victor Lazzarini <Victor.Lazzarini@mu.ie>
> wrote:
>
> > yes, we have already done that. But if we take previous version upgrades
> > experiences, we'll probably be breaking stuff left, right and center before
> > we can move forward.
> >
> > Prof. Victor Lazzarini
> > Maynooth University
> > Ireland
> >
> > On 14 Sep 2021, at 09:30, Rory Walsh <rorywalsh@ear.ie> wrote:
> >
> > 
> >
> >> The thing is that Cs7 will not be in a working condition for a good
> >> while, whereas 6.17 will be.
> >>
> >
> > I was under the impression that you would simply create a new cs7 branch,
> > merge 6.17 into it and continue from there, which would be the same as
> > continuing in 6.17, but offers a cleaner break?
> >
> >

I can only speak to what has worked for me in a commercial context, and what I see working in the companies I assess and consult for, but perhaps it will be helpful for considerations. I'm not saying I know the right answer for Csound, but I get to talk to companies in the trenches all the time, so I hear a lot of war stories. Please take this not as me saying "this is what Csound should do" (because I understand that the situation is not typical), but rather, perhaps it is helpful to know what I think a typical dev is likely to think Csound does or should do based on common practice at software shops. Apologies for the noise if this is all common knowledge.

I think the common expectation these days is that mainline (whether you call it main/trunk/master) should be "releasable". It might not *be the current* release, but the idea is, you could release it if you had to (say, to fail-forward after a bad issue was found in a public release). So it should always "just work", and have passed whatever automated tests are in place. The normal process being that as a dev, I don't get to merge to main if my work does not pass all regression tests. Most shops that have a really solid process these days will *rebase* main into the dev's feature branch, run the pipeline there, and then merge that back from master. This just ensures that if there ever is a git integration mess, it happens in the feature branch, and can be sorted out there: merging the feature branch into master post rebase becomes a formality that will always work.

In general, long-lived feature branches are considered something that should not be used more than necessary, but the example of something as dramatic as a new parser would be a good use case. I gather this has been called "develop". That's a bit more like older svn practices where branching and remerging was much less reliable, so one didn't just make feature branches willy nilly. These days, I don't see a "develop" typically, but that's just because each dev can cheaply make their own private branch and then do the rebase dance. That said, I don't think there's anything wrong with it, especially given that (I think?) there is not a CI pipeline so mature as to be 100% reliable as an indicator of releasable. (And to be honest, even mature companies, we don't see that gold standard much, maybe 20% of the time if that).

Some places fork off main for releases, but given that main is kept releasable, a full fork is not really necessary and most will just tag. Sometimes that becomes a staging branch if there is long lived user acceptance testing etc. That all depends on the reliability of their automated testing and their QA process.

Which I guess is my long winded way of saying that if were advising based on what I know so far and what I see causing the least issues in the wild, I would:

- keep main as releasable: a user should always be happy building and using main

- tag for releases off it, where releases are really more about collections of features and documentation, because main is always releasable

- keep develop as the target for stuff that might make things break: set the expectation that develop is *not* expected to be clean on any given day, though it probably is

- nonetheless, individual devs do feature branch off develop for their work so that you can try to keep develop buildable and ready to beta test 

- at some cadence, do integrations of develop to main: rebase main over develop, run tests, merge develop to main

- at some (possibly) other cadence, which may be determined by documentation instead, create tags off main, package, release

Re protecting against accidental writing, the usual practice I see is is that merging to main needs to be done through a pull request with some enforced policy of eyes on it and tests passing. 

Hopefully that is somewhat helpful and not just a bunch of noise! If there's one thing to take away from this, it's that rebasing will save everyone a lot of pain one day, if you aren't already doing it. When I had to start doing it that way I grumbled and then on the first giant git spaz I was like "ooohhhh, I see....we still get to go home at 5 because of rebasing...." :-)

iain

On Wed, Sep 15, 2021 at 12:48 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

But there's also an important point associated with your question. We have used develop as our default git hub branch for years.  The question is whether we should switch it back to master (and protect against accidental writing maybe?)

Prof. Victor Lazzarini

Maynooth University

Ireland

On 15 Sep 2021, at 20:35, Iain Duncan <iainduncanlists@gmail.com> wrote:



Thanks for clarifying that Victor, good to know. :-)

iain

On Wed, Sep 15, 2021 at 12:29 PM Victor Lazzarini <Victor.Lazzarini@mu.ie> wrote:

I don't think it will. We use master as our stable released code and develop as our ordinary development work, and feature/* as side feature development.

The proposal is to continue like this bumping the version to 7.0, but keep a maintenance 6.x branch from which we will do bugfix releases (which become master) until 7.0 is finally released.

Prof. Victor Lazzarini

Maynooth University

Ireland

On 15 Sep 2021, at 20:15, Iain Duncan <iainduncanlists@gmail.com> wrote:



If I may, I would like to suggest one thing from the side lines. I would recommend that the long lived development branch in which the parser work is happening *not* be main/master/trunk.   To people coming to csound from other programming areas, it creates a strongly negative impression if trunk doesn't always build and work, as this is the normal practice in commercial dev these days and to many, is a bit of a de facto sniff test for how development is conducted. The approach that will not scare these people off would be to have  6.x releases be tags from trunk, and the long lived develop branch is separate but can rebase 6.xx releases into itself to keep current with minor mainteance work from the 6.x mainline. (Develop can even have sub feature branches cut off of itself). This will ensure that trunk always builds with tests passing, and clearly indicates that develop is a moving target that is not expected or intended to be releasable at any point. 

hth!

iain

 

On Wed, Sep 15, 2021 at 11:58 AM joachim heintz <jh@joachimheintz.de> wrote:

yes sounds like a good solution, and somehow considering most arguments
from this discussion.
thanks for getting closer to CS7 ---
        joachim


On 15/09/2021 20:02, Victor Lazzarini wrote:
> I think this is a good compromise and I am in favour of it.
>
> Prof. Victor Lazzarini
> Maynooth University
> Ireland
>
>> On 15 Sep 2021, at 16:54, Steven Yi <stevenyi@gmail.com> wrote:
>>
>> 
>> Hi All,
>>
>> I'm happy to see this work making its way into the main development. I
>> think the stability is really important and I think we've discussed
>> this option before but I'd like to propose it again, which is to
>> create a stable branch from develop (csound6) where we can continue on
>> with csound6 maintenance and merge parser3 into develop and make
>> develop the branch for cs7 work.  I think since there's a number of
>> changes for 6.17 already happened, we could look to finish up 6.17
>> soon, then do the csound6 and parser3 merging after that release.
>>
>> One impact this may have though is that anyone using something like
>> homebrew who does builds from HEAD may get CS7 as develop is the
>> default branch.  As there will undoubtedly be some instabilities it
>> may cause some confusion but I imagine we just work through to help
>> downstream maintainers.
>>
>> Steven
>>
>> On Wed, Sep 15, 2021 at 7:42 AM andy fillebrown
>> <andy.fillebrown@gmail.com <mailto:andy.fillebrown@gmail.com>> wrote:
>>
>>
>>     Good points. To be clear, I think you're all doing a great job
>>     with Cabbage and Csound and I'm appreciative of the responsiveness
>>     in fixing bugs. I feel like both Cabbage and Csound are in really
>>     good shape, and while I'm very much looking forward to the new
>>     features in Csound 7, I'm even more looking forward to working
>>     with Csound 6 as-is. Csound 6 is very good software right now.
>>
>>     Thank you,
>>     ~ Andy Fillebrown / docEdub
>>
>>
>>
>>     On Wed, Sep 15, 2021 at 4:11 AM Rory Walsh <rorywalsh@ear.ie
>>     <mailto:rorywalsh@ear.ie>> wrote:
>>
>>         To be fair to you Andy, you really push Csound in ways the
>>         average users can only dream about. However, it's been a while
>>         since you reported any issues with Cabbage. As a member of the
>>         Cabbage forum, you know I tend to deal with issues as soon as
>>         they appear. And in the times you've made PRs I've never had
>>         any issues in merging. I'd be happy if you made more 😀
>>
>>         It looks like you've switched focus to CsoundWASM at the
>>         minute, so maybe you're taking a break from Cabbage. Hopefully
>>         by the time you return it will be better than ever ;)
>>
>>         Your WebXr stuff looks really impressive btw! I'm looking
>>         forward to following your progress there.
>>
>>
>>         On Wed, 15 Sept 2021 at 07:04, Victor Lazzarini
>>         <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>> wrote:
>>
>>             Thanks for this. I understand your point of view, and
>>             there is sense in it.
>>
>>             I just want to point out that, while not denying what you
>>             say, I don't agree that Csound is particularly buggy. In
>>             fact, on the contrary, it is quite mature as a technology.
>>
>>             The bugs you are reporting are to do with the web platform
>>             and that is of course on the edge, particularly as they
>>             have moved to a different compiler and are reworking that
>>             API. I can't comment on Cabbage bugs because that is a
>>             third party project we do not have anything to do with
>>             (apart from supporting), it is not Csound.
>>
>>             It is great that you are supporting that effort, and as
>>             you can see that bit has not yet been released so you are
>>             working with what can best be described as beta or even
>>             possibly alpha code. No wonder you are having second
>>             thoughts about using it, it's not really in production
>>             shape. However, this is not representative of the Csound
>>             code as a whole.
>>
>>             If you look at the Csound issue tracker, you will not see
>>             much action beyond these cutting edge platforms/tech. In
>>             fact, excluding web csound, I don't think there are any
>>             bug tickets currently open (we tend to try and address
>>             these as quickly as possible) and certainly no show
>>             stoppers as far as I can see (if there are I am happy to
>>             be corrected and will address them immediately).
>>
>>             Anyway, thanks again for your comments.
>>
>>             Prof. Victor Lazzarini
>>             Maynooth University
>>             Ireland
>>
>>>             On 15 Sep 2021, at 06:24, andy fillebrown
>>>             <andy.fillebrown@gmail.com
>>>             <mailto:andy.fillebrown@gmail.com>> wrote:
>>>
>>>             
>>>
>>>             Thanks for opening this up for discussion.
>>>
>>>             tldr; I love Csound but I'm tired of running into its
>>>             bugs. I vote for keeping the current parser for 6.17 if
>>>             the new parser can't coexist with it.
>>>
>>>             I very much want to use the new parser features but I do
>>>             not want to risk the stability of 6.17. There are many
>>>             changes in 6.17 that I am waiting for and it would be
>>>             frustrating to me if it brought in new issues due to the
>>>             new parser. I do not want to be stuck on 6.16 until the
>>>             new parser issues are fixed.
>>>
>>>             If there are not enough dev resources to maintain two
>>>             releases then I vote for stability over new parser.
>>>
>>>             Is there no way to put the new parser behind a command
>>>             line argument? Didn't the version 5 to 6 parser change
>>>             work that way? If that's not the case for version 6 to 7
>>>             then I'd rather see it pushed to 7, especially since the
>>>             API would change. Maybe make 7 more of a
>>>             transition/experimental release and move quickly to 8?
>>>             Just a thought
>>>
>>>             Regardless of what is decided I think it's important to
>>>             say that I feel like Csound is gaining a fair amount of
>>>             momentum in the past few years due to the decisions made
>>>             in the past by the lead devs, e.g. the move to Github,
>>>             switching from Scons to CMake, and the relatively smooth
>>>             transition from version 5 to 6. In hindsight these have
>>>             clearly been the right decisions, so I'm not too
>>>             concerned about how the new parser is handled. I trust
>>>             that the devs have the community's best interests in mind.
>>>
>>>             That being said, from my point of view it would be a
>>>             shame to lose the momentum gained from those good past
>>>             decisions by replacing the relatively stable parser with
>>>             an unknown. Csound has a history of being buggy and as an
>>>             artist, my choice to use Csound and Cabbage has been the
>>>             biggest risk in my toolchain due to the number of bugs I
>>>             have encountered. I have had to stop working on my
>>>             project several times this past year to fix issues in
>>>             Cabbage and Csound, and two weeks ago I came very close
>>>             to giving up on using Csound WASM in my WebXR project due
>>>             to show-stopping memory issues. Fortunately, I persisted
>>>             and was able to fix the issues, so I'm in a good place
>>>             now and I'm moving forward on my project nicely. The dev
>>>             fatigue I'm feeling from the Cabbage and Csound bugs is
>>>             real, though. I very much want to just make stuff with
>>>             these awesome tools you all have given us, and I feel
>>>             like version 6 is just now starting to become
>>>             satisfactorily stable enough to do that. I'm very much
>>>             looking forward to the maturity of the next release and I
>>>             feel like what's going to keep the momentum going the
>>>             best right now is stable releases with fewer bugs. That
>>>             is more important to me than the new parser.
>>>
>>>             Thanks for listening,
>>>             ~ Andy Fillebrown / docEdub
>>>
>>>
>>>
>>>             On Tue, Sep 14, 2021 at 1:20 PM Pete Goodeve
>>>             <pete.goodeve@computer.org
>>>             <mailto:pete.goodeve@computer.org>> wrote:
>>>
>>>                 A strong +1 on this from me.  Iain has echoed my own
>>>                 opinion far more
>>>                 clearly than I could!
>>>
>>>                 Thanks!
>>>
>>>                         -- Pete --
>>>
>>>                 On Tue, Sep 14, 2021 at 07:32:18AM -0700, Iain Duncan
>>>                 wrote:
>>>                 > Hi Victor and others, of course I'm not a csound
>>>                 dev and nor have I been
>>>                 > involved for many years (though I'm using it again
>>>                 now), so take what I say
>>>                 > with a grain of salt. I am, FWIW, a technical due
>>>                 diligence consultant to
>>>                 > software companies getting major investments or
>>>                 being acquired so talking
>>>                 > with software companies about their releases
>>>                 cycles, development processes,
>>>                 > etc, is my day job now, for everything from tiny
>>>                 shops to $1B monsters. And
>>>                 > an open source author of a much much smaller
>>>                 project, haha. My thoughts
>>>                 > from the sidelines:
>>>                 >
>>>                 > - The new parser sounds like a great step forward,
>>>                 kudos!
>>>                 > - If there is any risk of the merge of the new
>>>                 parser breaking things in 6,
>>>                 > when it comes out, because of uncaught backwards
>>>                 incompatibility at this
>>>                 > point, I think it should not be merged to 6. This
>>>                 is the kind of thing that
>>>                 > alienates users and creates negative impressions
>>>                 that can be very hard to
>>>                 > get over later, in my experience.
>>>                 > - As above for the API. People using the API in
>>>                 apps and frontends expect
>>>                 > API stability unless there is a major version
>>>                 number change. Breaking that
>>>                 > expectation can lose you some of the most important
>>>                 users, in my humble
>>>                 > opinion.
>>>                 > - The million dollar question: does the csound dev
>>>                 community/system have
>>>                 > the QA infrastructure/process in place to ensure
>>>                 the above won't be issues?
>>>                 > Please do not take that as  a value judgement,
>>>                 automating QA is hard work,
>>>                 > I honestly don't know what the situation is these
>>>                 days though I can see
>>>                 > it's much more automated than it was 10-15 years
>>>                 ago. But I think if the
>>>                 > answer is no or unknown, then merging to 6 is rash.
>>>                 > - Given the above, is there a compelling reason not
>>>                 to maintain a 6 stable
>>>                 > and 7-alpha version for some period of overlap?  I
>>>                 see this done sometimes
>>>                 > in both open source and commercial software for
>>>                 this type of situation.
>>>                 > When a public stable version is maintained and
>>>                 strictly tested, people are
>>>                 > much more forgiving about the bleeding edge on the
>>>                 next one. The 7-alpha
>>>                 > does not have to be 7 *as it is planned now*, it
>>>                 could be 6 with the new
>>>                 > parser and be the merge target for other features
>>>                 for some period (6
>>>                 > months, a year, whatever). In my experience, and
>>>                 from people I've spoken
>>>                 > to, maintaining a second release line is actually
>>>                 less work than it sounds
>>>                 > like it will be, as so much of the work for the
>>>                 first one is reusable. It
>>>                 > does not have to lead to the dreaded Python 2 to 3
>>>                 situation if handled
>>>                 > properly.
>>>                 > - An advantage of the above is that the new
>>>                 features become something
>>>                 > people can see. In my impression, a big problem
>>>                 with projects like csound,
>>>                 > where the system is very complex and most of the
>>>                 devs are juggling the rest
>>>                 > of their academic duties and so on, is that the
>>>                 development can come across
>>>                 > to public users as very hidden, or worse, as if
>>>                 it's not going on, just
>>>                 > because it's not visible to them in the way they
>>>                 are used to from
>>>                 > constantly releasing reference projects. Whether we
>>>                 agree with it or not,
>>>                 > visibility of new features moving along is a big
>>>                 part of what potential new
>>>                 > users look for. (I am guilty of not handling this
>>>                 well myself and have
>>>                 > resolved to try to fix it for Scheme for Max after
>>>                 0.3 this month!)
>>>                 >
>>>                 > Them's my two cents Canadian, with no expectation
>>>                 that anyone has any
>>>                 > reason to listen to me. :-)  Now that I am through
>>>                 my conference/thesis
>>>                 > first paper, I shall be using Csound more and would
>>>                 be happy to help test
>>>                 > builds.
>>>                 >
>>>                 > iain
>>>                 >
>>>                 > On Tue, Sep 14, 2021 at 2:57 AM Victor Lazzarini
>>>                 <Victor.Lazzarini@mu.ie <mailto:Victor.Lazzarini@mu.ie>>
>>>                 > wrote:
>>>                 >
>>>                 > > yes, we have already done that. But if we take
>>>                 previous version upgrades
>>>                 > > experiences, we'll probably be breaking stuff
>>>                 left, right and center before
>>>                 > > we can move forward.
>>>                 > >
>>>                 > > Prof. Victor Lazzarini
>>>                 > > Maynooth University
>>>                 > > Ireland
>>>                 > >
>>>                 > > On 14 Sep 2021, at 09:30, Rory Walsh
>>>                 <rorywalsh@ear.ie <mailto:rorywalsh@ear.ie>> wrote:
>>>                 > >
>>>                 > > 
>>>                 > >
>>>                 > >> The thing is that Cs7 will not be in a working
>>>                 condition for a good
>>>                 > >> while, whereas 6.17 will be.
>>>                 > >>
>>>                 > >
>>>                 > > I was under the impression that you would simply
>>>                 create a new cs7 branch,
>>>                 > > merge 6.17 into it and continue from there, which
>>>                 would be the same as
>>>                 > > continuing in 6.17, but offers a cleaner break?
>>>                 > >
>>>                 > >
>>>