Hi All,

Poking around again to see where we are with 6.10. I see most of the
same issues as the last time I raised this:

1. Windows build not thoroughly tested (We really need an actionable
plan for this!)
2. CsoundQT and Windows release: Seems like we should be packaging
last stable from CsoundQT project rather than building from Git as the
build on AppVeyor is doing.  (This was in reference to the email
thread with Tarmo where he confirmed that.)
3. AppVeyor build needs csdtests hooked in. I think the changes
Stephen did and that I built upon the CSD tests should be able to be
run now just fine (at least, works on my system).  I'm not sure how to
hook that into AppVeyor though.
4. AppVeyor build is erroring sporadically.  This seems due to the
vcpkg cache not refreshing (issue that Stephen diagnosed). I think it
was determined that it would require Michael to determine what to do
as it had to do with code he introduced?

Anything else?  The WASM build seems to have stabilized with the
TOTAL_MEMORY setting now and I think I feel comfortable enough that
that would be good to go. I have not done much testing at all on
Android though.

Hi,

On reede, 3. november 2017 17:41.05 EET you wrote:
> 2. CsoundQT and Windows release: Seems like we should be packaging
> last stable from CsoundQT project rather than building from Git as the
> build on AppVeyor is doing.  (This was in reference to the email
> thread with Tarmo where he confirmed that.)

I have not been able to build CsoundQt agains the Csound version downloaded 
from AppVeyor build but I definitely need to test if CsoundQt it works OK on 
Windows against Csound 6.10. Is there are pre-release minimal Csound package 
or someone can prepare a zip file with the libraries and plugins?

I think the AppVeryor build is great thing for getting easily latest builds 
but is it also the version that is going to be included in the Windows 
installer? Or who and how builds that? On MinGW or MSVC?

Otherwise I would prepare CsoundQt 0.9.5 (release candidate is out) for the 
release, that is not very different from previous stable release (0.9.4.1) but 
with some improvements.

Thanks!

Hi Tarmo,

Michael has been the one responsible for releases on Windows so he'd
be the final word, but I think it's the intention to have releases
from AppVeyor moving forward.  However, it looks to me that the
AppVeyor build is still continuing to fail:

https://ci.appveyor.com/project/csound/csound/history

When there is a successful build though, the build artifacts are an
installer and a minimal zip, for example:

https://ci.appveyor.com/project/csound/csound/build/1.0.732/artifacts

There's the related discussion about a platform installer on Github,
but that seems like it will take time to sort out, so probably
shouldn't be counted on for 6.10.

Pinging other developers: 6.10 is taking longer and longer to get
released.  I've mentioned the issues I saw in the first email in this
thread.  Could we discuss what needs to get done to get 6.10 out?

steven




On Fri, Nov 3, 2017 at 5:30 PM, Tarmo Johannes  wrote:
> Hi,
>
> On reede, 3. november 2017 17:41.05 EET you wrote:
>> 2. CsoundQT and Windows release: Seems like we should be packaging
>> last stable from CsoundQT project rather than building from Git as the
>> build on AppVeyor is doing.  (This was in reference to the email
>> thread with Tarmo where he confirmed that.)
>
> I have not been able to build CsoundQt agains the Csound version downloaded
> from AppVeyor build but I definitely need to test if CsoundQt it works OK on
> Windows against Csound 6.10. Is there are pre-release minimal Csound package
> or someone can prepare a zip file with the libraries and plugins?
>
> I think the AppVeryor build is great thing for getting easily latest builds
> but is it also the version that is going to be included in the Windows
> installer? Or who and how builds that? On MinGW or MSVC?
>
> Otherwise I would prepare CsoundQt 0.9.5 (release candidate is out) for the
> release, that is not very different from previous stable release (0.9.4.1) but
> with some improvements.
>
> Thanks!

Hi,

it is absolutley fine if Michael does the build using AppVeyor, if it meets 
everyone's needs. I just want to be able to build test-releases myself, too, 
but I will figure it out sooner or later.
Only thing needed to do is to pull CsoundQt from master branch  for the 
"installer-build".
Michael sent me some hints how it can be changed (it Csound sources) but I 
have no access to Csound repo directly and unfortunately also have very little 
"Windows" time for experiments these days. 

Anyway, I think it cannot be released before a true release-candidate for 
Windows is accessible for testing and several users have approved that does 
work. I think that it can be still cosidered to leave CsoundQt out from this 
release on but then I need to have an independent installer ready on CsoundQt 
release page before Csound release -  otherewise we get tons of complaints who 
are used to double click on the CsoundQt icon as first thing.

Another thing I want to figure out before release is stability with the new 
UDPServer changes. In CsoundQt in some reason csoundCleanUp() does not close 
the UDPServer and it stays hanging and causes crash on next start or incoming 
messages. I think the new UDP driven features are very important and I would 
really want to get it working within CsoundQt. I try to do some testing and 
experiments and will discuss with Victor to see the causes.

Thanks!
tarmo




On Monday, November 6, 2017 6:59:09 PM EET Steven Yi wrote:
> Hi Tarmo,
> 
> Michael has been the one responsible for releases on Windows so he'd
> be the final word, but I think it's the intention to have releases
> from AppVeyor moving forward.  However, it looks to me that the
> AppVeyor build is still continuing to fail:
> 
> https://ci.appveyor.com/project/csound/csound/history
> 
> When there is a successful build though, the build artifacts are an
> installer and a minimal zip, for example:
> 
> https://ci.appveyor.com/project/csound/csound/build/1.0.732/artifacts
> 
> There's the related discussion about a platform installer on Github,
> but that seems like it will take time to sort out, so probably
> shouldn't be counted on for 6.10.
> 
> Pinging other developers: 6.10 is taking longer and longer to get
> released.  I've mentioned the issues I saw in the first email in this
> thread.  Could we discuss what needs to get done to get 6.10 out?
> 
> steven
> 
> On Fri, Nov 3, 2017 at 5:30 PM, Tarmo Johannes  wrote:
> > Hi,
> > 
> > On reede, 3. november 2017 17:41.05 EET you wrote:
> >> 2. CsoundQT and Windows release: Seems like we should be packaging
> >> last stable from CsoundQT project rather than building from Git as the
> >> build on AppVeyor is doing.  (This was in reference to the email
> >> thread with Tarmo where he confirmed that.)
> > 
> > I have not been able to build CsoundQt agains the Csound version
> > downloaded
> > from AppVeyor build but I definitely need to test if CsoundQt it works OK
> > on Windows against Csound 6.10. Is there are pre-release minimal Csound
> > package or someone can prepare a zip file with the libraries and plugins?
> > 
> > I think the AppVeryor build is great thing for getting easily latest
> > builds
> > but is it also the version that is going to be included in the Windows
> > installer? Or who and how builds that? On MinGW or MSVC?
> > 
> > Otherwise I would prepare CsoundQt 0.9.5 (release candidate is out) for
> > the
> > release, that is not very different from previous stable release (0.9.4.1)
> > but with some improvements.
> > 
> > Thanks!

Hi,

> Anyway, I think it cannot be released before a true release-candidate for 
> Windows is accessible for testing and several users have approved that does 
> work. I think that it can be still cosidered to leave CsoundQt out from this 
> release on but then I need to have an independent installer ready on CsoundQt 
> release page before Csound release -  otherewise we get tons of complaints who 
> are used to double click on the CsoundQt icon as first thing.
>

I think the online installer will help in fixing both of those problems.
Check this out, Tarmo ->
https://stackoverflow.com/questions/34318934/qt-installer-framework-auto-update.
Every time there's a CsoundQt beta release we can suggest every user to
update and report back. Also, you wouldn't need another installer
because the idea would be to have only one installer for installing Core
and the interfaces.

The only issue is that this is absolutely not going to be ready for
6.10! So there should be a temporary solution in place.

Major changes internally (corfiles) may need time for confidence

Release notes are not complete now

There are unexplained issues in DSSI/Ladspa.

I have updated the AppVeyor build to use the "master" branch of
CsoundQt. This may require some debugging.

I have done some cleanup in the WebAssembly code, but audio
performance is still not always satisfactory. It looks like
AudioWorklet will be needed to ensure adequate performance. Note that
the default number of sample frames per audio processing callback is
2048, which at 44100 Hz is 46 milliseconds. AudioWorklet is said to be
available behind a flag in release 63 of Chrome (I am currently on
62). I am going to track this. Csound will run in its own thread in
the worklet, and communicate with the JavaScript context via
asynchronous message passing.

Regards,
Mike


-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, Nov 7, 2017 at 4:16 PM, jpff  wrote:
> Major changes internally (corfiles) may need time for confidence
>
> Release notes are not complete now
>
> There are unexplained issues in DSSI/Ladspa.
>

I've put in a fair amount of work already on AudioWorklet:

http://github.com/kunstmusik/csound-audioworklet

and discussions with Web Audio folks at:

https://bugs.chromium.org/p/chromium/issues/detail?id=774564#c16
https://github.com/WebAudio/web-audio-api/issues/1439

The latest approach I'm working on follows what the Faust team did but
with some changes, trying to reuse more of what we have already. Right
now, the major holdup is that there is no MessagePort implemented for
the AudioWorkletProcessor.  Jari Kleimola has already implemented
workarounds which work and is, I think,  the path to follow for now.
I'll have more information about this once the last bits are
implemented.

On Tue, Nov 7, 2017 at 6:41 PM, Michael Gogins  wrote:
> I have updated the AppVeyor build to use the "master" branch of
> CsoundQt. This may require some debugging.
>
> I have done some cleanup in the WebAssembly code, but audio
> performance is still not always satisfactory. It looks like
> AudioWorklet will be needed to ensure adequate performance. Note that
> the default number of sample frames per audio processing callback is
> 2048, which at 44100 Hz is 46 milliseconds. AudioWorklet is said to be
> available behind a flag in release 63 of Chrome (I am currently on
> 62). I am going to track this. Csound will run in its own thread in
> the worklet, and communicate with the JavaScript context via
> asynchronous message passing.
>
> Regards,
> Mike
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Nov 7, 2017 at 4:16 PM, jpff  wrote:
>> Major changes internally (corfiles) may need time for confidence
>>
>> Release notes are not complete now
>>
>> There are unexplained issues in DSSI/Ladspa.
>>

Yes, I have been looking at your discussion in the Chromium and WebAudio issues.

What is your impression -- do these people know what they are doing,
are we going to end up with something we can use? How long might that
be?

Best,
Mike



-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, Nov 7, 2017 at 6:50 PM, Steven Yi  wrote:
> I've put in a fair amount of work already on AudioWorklet:
>
> http://github.com/kunstmusik/csound-audioworklet
>
> and discussions with Web Audio folks at:
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=774564#c16
> https://github.com/WebAudio/web-audio-api/issues/1439
>
> The latest approach I'm working on follows what the Faust team did but
> with some changes, trying to reuse more of what we have already. Right
> now, the major holdup is that there is no MessagePort implemented for
> the AudioWorkletProcessor.  Jari Kleimola has already implemented
> workarounds which work and is, I think,  the path to follow for now.
> I'll have more information about this once the last bits are
> implemented.
>
> On Tue, Nov 7, 2017 at 6:41 PM, Michael Gogins  wrote:
>> I have updated the AppVeyor build to use the "master" branch of
>> CsoundQt. This may require some debugging.
>>
>> I have done some cleanup in the WebAssembly code, but audio
>> performance is still not always satisfactory. It looks like
>> AudioWorklet will be needed to ensure adequate performance. Note that
>> the default number of sample frames per audio processing callback is
>> 2048, which at 44100 Hz is 46 milliseconds. AudioWorklet is said to be
>> available behind a flag in release 63 of Chrome (I am currently on
>> 62). I am going to track this. Csound will run in its own thread in
>> the worklet, and communicate with the JavaScript context via
>> asynchronous message passing.
>>
>> Regards,
>> Mike
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Tue, Nov 7, 2017 at 4:16 PM, jpff  wrote:
>>> Major changes internally (corfiles) may need time for confidence
>>>
>>> Release notes are not complete now
>>>
>>> There are unexplained issues in DSSI/Ladspa.
>>>

There's a lot of WebAudio that I don't think makes sense as a design,
but I don't think those issues matter much now. What does matter is
our use cases for Csound, which I do think AudioWorklet will address.
I can say that a bit more confidently after seeing Jari's work in
operation in Chrome Canary, as it largely has the same requirements as
we do. That said, there's more than a few hacks involved at the
moment, but at least a fair amount can get working. Once more of
AudioWorklet is implemented and stabilizes, I think we can then ignore
most of the WebAudio API and be alright to use Csound as we do on
other platforms.

As for estimates, I really don't have an idea as to when things will
land in stable Chrome or when other browsers will take on
AudioWorklets. As far as I know, only Chrome has a partial
implementation at this time. I guess at this point all we can do is
try to get what we can working and provide as much feedback as
possible to make sure our use cases get covered before anything is
finalized.

On Tue, Nov 7, 2017 at 7:30 PM, Michael Gogins  wrote:
> Yes, I have been looking at your discussion in the Chromium and WebAudio issues.
>
> What is your impression -- do these people know what they are doing,
> are we going to end up with something we can use? How long might that
> be?
>
> Best,
> Mike
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Nov 7, 2017 at 6:50 PM, Steven Yi  wrote:
>> I've put in a fair amount of work already on AudioWorklet:
>>
>> http://github.com/kunstmusik/csound-audioworklet
>>
>> and discussions with Web Audio folks at:
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=774564#c16
>> https://github.com/WebAudio/web-audio-api/issues/1439
>>
>> The latest approach I'm working on follows what the Faust team did but
>> with some changes, trying to reuse more of what we have already. Right
>> now, the major holdup is that there is no MessagePort implemented for
>> the AudioWorkletProcessor.  Jari Kleimola has already implemented
>> workarounds which work and is, I think,  the path to follow for now.
>> I'll have more information about this once the last bits are
>> implemented.
>>
>> On Tue, Nov 7, 2017 at 6:41 PM, Michael Gogins  wrote:
>>> I have updated the AppVeyor build to use the "master" branch of
>>> CsoundQt. This may require some debugging.
>>>
>>> I have done some cleanup in the WebAssembly code, but audio
>>> performance is still not always satisfactory. It looks like
>>> AudioWorklet will be needed to ensure adequate performance. Note that
>>> the default number of sample frames per audio processing callback is
>>> 2048, which at 44100 Hz is 46 milliseconds. AudioWorklet is said to be
>>> available behind a flag in release 63 of Chrome (I am currently on
>>> 62). I am going to track this. Csound will run in its own thread in
>>> the worklet, and communicate with the JavaScript context via
>>> asynchronous message passing.
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Tue, Nov 7, 2017 at 4:16 PM, jpff  wrote:
>>>> Major changes internally (corfiles) may need time for confidence
>>>>
>>>> Release notes are not complete now
>>>>
>>>> There are unexplained issues in DSSI/Ladspa.
>>>>

Let me know whatever I can do to help this work out. I completely
agree about feedback and use cases. How much actual audio
programming/DSP background do these guys have?

Best,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, Nov 7, 2017 at 10:50 PM, Steven Yi  wrote:
> There's a lot of WebAudio that I don't think makes sense as a design,
> but I don't think those issues matter much now. What does matter is
> our use cases for Csound, which I do think AudioWorklet will address.
> I can say that a bit more confidently after seeing Jari's work in
> operation in Chrome Canary, as it largely has the same requirements as
> we do. That said, there's more than a few hacks involved at the
> moment, but at least a fair amount can get working. Once more of
> AudioWorklet is implemented and stabilizes, I think we can then ignore
> most of the WebAudio API and be alright to use Csound as we do on
> other platforms.
>
> As for estimates, I really don't have an idea as to when things will
> land in stable Chrome or when other browsers will take on
> AudioWorklets. As far as I know, only Chrome has a partial
> implementation at this time. I guess at this point all we can do is
> try to get what we can working and provide as much feedback as
> possible to make sure our use cases get covered before anything is
> finalized.
>
> On Tue, Nov 7, 2017 at 7:30 PM, Michael Gogins  wrote:
>> Yes, I have been looking at your discussion in the Chromium and WebAudio issues.
>>
>> What is your impression -- do these people know what they are doing,
>> are we going to end up with something we can use? How long might that
>> be?
>>
>> Best,
>> Mike
>>
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Tue, Nov 7, 2017 at 6:50 PM, Steven Yi  wrote:
>>> I've put in a fair amount of work already on AudioWorklet:
>>>
>>> http://github.com/kunstmusik/csound-audioworklet
>>>
>>> and discussions with Web Audio folks at:
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=774564#c16
>>> https://github.com/WebAudio/web-audio-api/issues/1439
>>>
>>> The latest approach I'm working on follows what the Faust team did but
>>> with some changes, trying to reuse more of what we have already. Right
>>> now, the major holdup is that there is no MessagePort implemented for
>>> the AudioWorkletProcessor.  Jari Kleimola has already implemented
>>> workarounds which work and is, I think,  the path to follow for now.
>>> I'll have more information about this once the last bits are
>>> implemented.
>>>
>>> On Tue, Nov 7, 2017 at 6:41 PM, Michael Gogins  wrote:
>>>> I have updated the AppVeyor build to use the "master" branch of
>>>> CsoundQt. This may require some debugging.
>>>>
>>>> I have done some cleanup in the WebAssembly code, but audio
>>>> performance is still not always satisfactory. It looks like
>>>> AudioWorklet will be needed to ensure adequate performance. Note that
>>>> the default number of sample frames per audio processing callback is
>>>> 2048, which at 44100 Hz is 46 milliseconds. AudioWorklet is said to be
>>>> available behind a flag in release 63 of Chrome (I am currently on
>>>> 62). I am going to track this. Csound will run in its own thread in
>>>> the worklet, and communicate with the JavaScript context via
>>>> asynchronous message passing.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Tue, Nov 7, 2017 at 4:16 PM, jpff  wrote:
>>>>> Major changes internally (corfiles) may need time for confidence
>>>>>
>>>>> Release notes are not complete now
>>>>>
>>>>> There are unexplained issues in DSSI/Ladspa.
>>>>>

Thanks, I think there isn't much to do at the moment. I had a busy day
so didn't get around to finishing the proof-of-concept, but hope to
get to that tomorrow.  After that, we should probably wait until
MessagePort lands, then update the POC code, and really get our
testing going at that point, evaluating what else we may need. We
could look at cleaning up things and bringing it all back into the
main Csound repo around then.

As for audio programming/DSP, I have my guesses but I don't really
know what the backgrounds are of the people who are implementing Web
Audio. It's probably not good for me to say anything else at this
point, but I'll be thankful when they get AudioWorklet done. :)


On Wed, Nov 8, 2017 at 7:28 AM, Michael Gogins  wrote:
> Let me know whatever I can do to help this work out. I completely
> agree about feedback and use cases. How much actual audio
> programming/DSP background do these guys have?
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Nov 7, 2017 at 10:50 PM, Steven Yi  wrote:
>> There's a lot of WebAudio that I don't think makes sense as a design,
>> but I don't think those issues matter much now. What does matter is
>> our use cases for Csound, which I do think AudioWorklet will address.
>> I can say that a bit more confidently after seeing Jari's work in
>> operation in Chrome Canary, as it largely has the same requirements as
>> we do. That said, there's more than a few hacks involved at the
>> moment, but at least a fair amount can get working. Once more of
>> AudioWorklet is implemented and stabilizes, I think we can then ignore
>> most of the WebAudio API and be alright to use Csound as we do on
>> other platforms.
>>
>> As for estimates, I really don't have an idea as to when things will
>> land in stable Chrome or when other browsers will take on
>> AudioWorklets. As far as I know, only Chrome has a partial
>> implementation at this time. I guess at this point all we can do is
>> try to get what we can working and provide as much feedback as
>> possible to make sure our use cases get covered before anything is
>> finalized.
>>
>> On Tue, Nov 7, 2017 at 7:30 PM, Michael Gogins  wrote:
>>> Yes, I have been looking at your discussion in the Chromium and WebAudio issues.
>>>
>>> What is your impression -- do these people know what they are doing,
>>> are we going to end up with something we can use? How long might that
>>> be?
>>>
>>> Best,
>>> Mike
>>>
>>>
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Tue, Nov 7, 2017 at 6:50 PM, Steven Yi  wrote:
>>>> I've put in a fair amount of work already on AudioWorklet:
>>>>
>>>> http://github.com/kunstmusik/csound-audioworklet
>>>>
>>>> and discussions with Web Audio folks at:
>>>>
>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=774564#c16
>>>> https://github.com/WebAudio/web-audio-api/issues/1439
>>>>
>>>> The latest approach I'm working on follows what the Faust team did but
>>>> with some changes, trying to reuse more of what we have already. Right
>>>> now, the major holdup is that there is no MessagePort implemented for
>>>> the AudioWorkletProcessor.  Jari Kleimola has already implemented
>>>> workarounds which work and is, I think,  the path to follow for now.
>>>> I'll have more information about this once the last bits are
>>>> implemented.
>>>>
>>>> On Tue, Nov 7, 2017 at 6:41 PM, Michael Gogins  wrote:
>>>>> I have updated the AppVeyor build to use the "master" branch of
>>>>> CsoundQt. This may require some debugging.
>>>>>
>>>>> I have done some cleanup in the WebAssembly code, but audio
>>>>> performance is still not always satisfactory. It looks like
>>>>> AudioWorklet will be needed to ensure adequate performance. Note that
>>>>> the default number of sample frames per audio processing callback is
>>>>> 2048, which at 44100 Hz is 46 milliseconds. AudioWorklet is said to be
>>>>> available behind a flag in release 63 of Chrome (I am currently on
>>>>> 62). I am going to track this. Csound will run in its own thread in
>>>>> the worklet, and communicate with the JavaScript context via
>>>>> asynchronous message passing.
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Tue, Nov 7, 2017 at 4:16 PM, jpff  wrote:
>>>>>> Major changes internally (corfiles) may need time for confidence
>>>>>>
>>>>>> Release notes are not complete now
>>>>>>
>>>>>> There are unexplained issues in DSSI/Ladspa.
>>>>>>

These are all ok now.  Do we have a plan?

On Tue, 7 Nov 2017, jpff wrote:

> Major changes internally (corfiles) may need time for confidence
>
> Release notes are not complete now
>
> There are unexplained issues in DSSI/Ladspa.
>
> otherwise I think this is way overdue

I would like to wait until we get some feedback on the stability of
CsoundQt as packaged in the current installer built by AppVeyor (no
later than November 11).

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Mon, Nov 13, 2017 at 12:24 PM, Victor Lazzarini
 wrote:
> I am ready to go at any point.
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
> On 13 Nov 2017, at 17:16, jpff  wrote:
>
> These are all ok now.  Do we have a plan?
>
> On Tue, 7 Nov 2017, jpff wrote:
>
> Major changes internally (corfiles) may need time for confidence
>
>
> Release notes are not complete now
>
>
> There are unexplained issues in DSSI/Ladspa.
>
>
> otherwise I think this is way overdue
>

Excuse me, no EARLIER than November 11...

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Mon, Nov 13, 2017 at 1:05 PM, Michael Gogins
 wrote:
> I would like to wait until we get some feedback on the stability of
> CsoundQt as packaged in the current installer built by AppVeyor (no
> later than November 11).
>
> Regards,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Mon, Nov 13, 2017 at 12:24 PM, Victor Lazzarini
>  wrote:
>> I am ready to go at any point.
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>> On 13 Nov 2017, at 17:16, jpff  wrote:
>>
>> These are all ok now.  Do we have a plan?
>>
>> On Tue, 7 Nov 2017, jpff wrote:
>>
>> Major changes internally (corfiles) may need time for confidence
>>
>>
>> Release notes are not complete now
>>
>>
>> There are unexplained issues in DSSI/Ladspa.
>>
>>
>> otherwise I think this is way overdue
>>

I mentioned on Github[1], but in case it was hidden, I'll raise the
point that we've discussed using only stable releases of CsoundQt, got
agreement to it from Tarmo, and were building the installer with
stable CsoundQt but it was reverted back to develop again. I think
testing CsoundQt beta code complicates testing core Csound, which
should be a big enough task considering the move to VS.  Unless I'm
missing something, stable CsoundQT should work with Csound 6.10 since
the API has not changed in a breaking way, yes?  In other words, I
don't understand the value in getting users to test both a dev version
of CsoundQt and our Csound release candidate at the same time. From
what I see, if I test the installer with with a stable CsoundQt and
see a change in behavior, I can guess with some confidence that the
source of the problem is Csound.  But with dev CsoundQt and release
candidate Csound, I'll have to guess if its a CsoundQt problem or
Csound one. (And couldn't CsoundQt dev build users just install that
on their own to test?)

Also, I'm pretty sure CsoundQt in the Mac installer is the last
stable, not dev. Shouldn't that be the same across platforms?

That all said, I also think the Windows release needs further testing.
Last I remember, I was able to use Blue with my own Windows Visual
Studio build, but Michael had crashes with Blue and the Appveyor
Windows build. I'm getting through some other work today but I am
planning to spend time tomorrow (Tuesday) on Windows testing (local VS
build, AppVeyor installer, with Blue, with CSD tests, API, etc.).

However, I'm bothered by the amount of time necessary to resolve
testing on Windows. (BTW: I'm not sure I understand Michael's comments
as it's already November 13th?).  I would like to suggest this:

1. Target Sunday, November 19th for a closing date for 6.10 code.
This gives a fair amount of time to do testing this week. I think that
should give enough time to get Rasmus' squinewave code integrated as
well as look at bug 868 (https://github.com/csound/csound/issues/868),
Thorin's reported issue dealing with live coding and schedule.
2. I'll go ahead and do an update of coverity branch in a moment and
we can try to update regularly this week to catch any last minute
issues.

On Sunday, we can do:

1. Create a release branch. Update version strings, etc. and build
installers/release zips.
2. Do release for all platforms except Windows (Linux, OSX, iOS, Android, WASM)
3. Finish release, code is merged into develop and master
4. Create hotfix branch for Windows release (i.e., 6.10.0_win).  The
hotfix would here be branched from master.  This would mean Windows
build testing could keep going and use only code from the release and
no new development code.
5. When Windows release is done, merge back into master and develop.

If Windows gets enough testing this week where we'd feel comfortable
with a release, then we could skip 4 and 5 of course.

How's that for a game plan?

steven


[1] - https://github.com/csound/csound/commit/aa43ac375c1365fff4c4fa5194ffa9b639a2fc4c#commitcomment-25564649


On Mon, Nov 13, 2017 at 1:07 PM, Michael Gogins
 wrote:
> Excuse me, no EARLIER than November 11...
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Mon, Nov 13, 2017 at 1:05 PM, Michael Gogins
>  wrote:
>> I would like to wait until we get some feedback on the stability of
>> CsoundQt as packaged in the current installer built by AppVeyor (no
>> later than November 11).
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Mon, Nov 13, 2017 at 12:24 PM, Victor Lazzarini
>>  wrote:
>>> I am ready to go at any point.
>>>
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>>
>>> On 13 Nov 2017, at 17:16, jpff  wrote:
>>>
>>> These are all ok now.  Do we have a plan?
>>>
>>> On Tue, 7 Nov 2017, jpff wrote:
>>>
>>> Major changes internally (corfiles) may need time for confidence
>>>
>>>
>>> Release notes are not complete now
>>>
>>>
>>> There are unexplained issues in DSSI/Ladspa.
>>>
>>>
>>> otherwise I think this is way overdue
>>>

I'm OK with your plan, actually.

After the release is fully complete, as you say, we can go back to
producing the producing the AppVeyor build with the develop branch and
test with that.

Best,
Mke



-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Mon, Nov 13, 2017 at 3:47 PM, Steven Yi  wrote:
> I mentioned on Github[1], but in case it was hidden, I'll raise the
> point that we've discussed using only stable releases of CsoundQt, got
> agreement to it from Tarmo, and were building the installer with
> stable CsoundQt but it was reverted back to develop again. I think
> testing CsoundQt beta code complicates testing core Csound, which
> should be a big enough task considering the move to VS.  Unless I'm
> missing something, stable CsoundQT should work with Csound 6.10 since
> the API has not changed in a breaking way, yes?  In other words, I
> don't understand the value in getting users to test both a dev version
> of CsoundQt and our Csound release candidate at the same time. From
> what I see, if I test the installer with with a stable CsoundQt and
> see a change in behavior, I can guess with some confidence that the
> source of the problem is Csound.  But with dev CsoundQt and release
> candidate Csound, I'll have to guess if its a CsoundQt problem or
> Csound one. (And couldn't CsoundQt dev build users just install that
> on their own to test?)
>
> Also, I'm pretty sure CsoundQt in the Mac installer is the last
> stable, not dev. Shouldn't that be the same across platforms?
>
> That all said, I also think the Windows release needs further testing.
> Last I remember, I was able to use Blue with my own Windows Visual
> Studio build, but Michael had crashes with Blue and the Appveyor
> Windows build. I'm getting through some other work today but I am
> planning to spend time tomorrow (Tuesday) on Windows testing (local VS
> build, AppVeyor installer, with Blue, with CSD tests, API, etc.).
>
> However, I'm bothered by the amount of time necessary to resolve
> testing on Windows. (BTW: I'm not sure I understand Michael's comments
> as it's already November 13th?).  I would like to suggest this:
>
> 1. Target Sunday, November 19th for a closing date for 6.10 code.
> This gives a fair amount of time to do testing this week. I think that
> should give enough time to get Rasmus' squinewave code integrated as
> well as look at bug 868 (https://github.com/csound/csound/issues/868),
> Thorin's reported issue dealing with live coding and schedule.
> 2. I'll go ahead and do an update of coverity branch in a moment and
> we can try to update regularly this week to catch any last minute
> issues.
>
> On Sunday, we can do:
>
> 1. Create a release branch. Update version strings, etc. and build
> installers/release zips.
> 2. Do release for all platforms except Windows (Linux, OSX, iOS, Android, WASM)
> 3. Finish release, code is merged into develop and master
> 4. Create hotfix branch for Windows release (i.e., 6.10.0_win).  The
> hotfix would here be branched from master.  This would mean Windows
> build testing could keep going and use only code from the release and
> no new development code.
> 5. When Windows release is done, merge back into master and develop.
>
> If Windows gets enough testing this week where we'd feel comfortable
> with a release, then we could skip 4 and 5 of course.
>
> How's that for a game plan?
>
> steven
>
>
> [1] - https://github.com/csound/csound/commit/aa43ac375c1365fff4c4fa5194ffa9b639a2fc4c#commitcomment-25564649
>
>
> On Mon, Nov 13, 2017 at 1:07 PM, Michael Gogins
>  wrote:
>> Excuse me, no EARLIER than November 11...
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Mon, Nov 13, 2017 at 1:05 PM, Michael Gogins
>>  wrote:
>>> I would like to wait until we get some feedback on the stability of
>>> CsoundQt as packaged in the current installer built by AppVeyor (no
>>> later than November 11).
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Mon, Nov 13, 2017 at 12:24 PM, Victor Lazzarini
>>>  wrote:
>>>> I am ready to go at any point.
>>>>
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>>
>>>> On 13 Nov 2017, at 17:16, jpff  wrote:
>>>>
>>>> These are all ok now.  Do we have a plan?
>>>>
>>>> On Tue, 7 Nov 2017, jpff wrote:
>>>>
>>>> Major changes internally (corfiles) may need time for confidence
>>>>
>>>>
>>>> Release notes are not complete now
>>>>
>>>>
>>>> There are unexplained issues in DSSI/Ladspa.
>>>>
>>>>
>>>> otherwise I think this is way overdue
>>>>

I think Tarmo, who is the main maintainer of CsoundQt, should decide
whether it remains as part of the AppVeyor build.

There are advantages to having CsoundQt built along with Csound,
especially that binary compatibility is assured.

As to the installer branch, I'm not making up my mind until I see that
the installer is a better experience for the users.

Regards,
Mike

-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, Nov 14, 2017 at 2:42 PM, Rory Walsh  wrote:
> Hi guys, I just wanted to make sure we're all on the same page here. As far
> I understand, following discussions that arose from the Csound conference,
> the plan as we move forward is for the Csound project itself to stop
> building frontends completely, unless they are part of the official project.
> A new Csound installer branch will be set up (Guillermo is currently working
> on this). That installer will look after the packaging of Csound and all 3rd
> party frontends, retrieving them from their respective sites, github or
> otherwise. So after 6.10 CsoundQT will no longer even be part of the
> AppVeyor build. I really think this is a positive step, and one that should
> simplify the release process of Csound. Does this sound like a good summary
> of the situation?
>
>
>
> On 13 November 2017 at 21:13, Michael Gogins 
> wrote:
>>
>> I'm OK with your plan, actually.
>>
>> After the release is fully complete, as you say, we can go back to
>> producing the producing the AppVeyor build with the develop branch and
>> test with that.
>>
>> Best,
>> Mke
>>
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Mon, Nov 13, 2017 at 3:47 PM, Steven Yi  wrote:
>> > I mentioned on Github[1], but in case it was hidden, I'll raise the
>> > point that we've discussed using only stable releases of CsoundQt, got
>> > agreement to it from Tarmo, and were building the installer with
>> > stable CsoundQt but it was reverted back to develop again. I think
>> > testing CsoundQt beta code complicates testing core Csound, which
>> > should be a big enough task considering the move to VS.  Unless I'm
>> > missing something, stable CsoundQT should work with Csound 6.10 since
>> > the API has not changed in a breaking way, yes?  In other words, I
>> > don't understand the value in getting users to test both a dev version
>> > of CsoundQt and our Csound release candidate at the same time. From
>> > what I see, if I test the installer with with a stable CsoundQt and
>> > see a change in behavior, I can guess with some confidence that the
>> > source of the problem is Csound.  But with dev CsoundQt and release
>> > candidate Csound, I'll have to guess if its a CsoundQt problem or
>> > Csound one. (And couldn't CsoundQt dev build users just install that
>> > on their own to test?)
>> >
>> > Also, I'm pretty sure CsoundQt in the Mac installer is the last
>> > stable, not dev. Shouldn't that be the same across platforms?
>> >
>> > That all said, I also think the Windows release needs further testing.
>> > Last I remember, I was able to use Blue with my own Windows Visual
>> > Studio build, but Michael had crashes with Blue and the Appveyor
>> > Windows build. I'm getting through some other work today but I am
>> > planning to spend time tomorrow (Tuesday) on Windows testing (local VS
>> > build, AppVeyor installer, with Blue, with CSD tests, API, etc.).
>> >
>> > However, I'm bothered by the amount of time necessary to resolve
>> > testing on Windows. (BTW: I'm not sure I understand Michael's comments
>> > as it's already November 13th?).  I would like to suggest this:
>> >
>> > 1. Target Sunday, November 19th for a closing date for 6.10 code.
>> > This gives a fair amount of time to do testing this week. I think that
>> > should give enough time to get Rasmus' squinewave code integrated as
>> > well as look at bug 868 (https://github.com/csound/csound/issues/868),
>> > Thorin's reported issue dealing with live coding and schedule.
>> > 2. I'll go ahead and do an update of coverity branch in a moment and
>> > we can try to update regularly this week to catch any last minute
>> > issues.
>> >
>> > On Sunday, we can do:
>> >
>> > 1. Create a release branch. Update version strings, etc. and build
>> > installers/release zips.
>> > 2. Do release for all platforms except Windows (Linux, OSX, iOS,
>> > Android, WASM)
>> > 3. Finish release, code is merged into develop and master
>> > 4. Create hotfix branch for Windows release (i.e., 6.10.0_win).  The
>> > hotfix would here be branched from master.  This would mean Windows
>> > build testing could keep going and use only code from the release and
>> > no new development code.
>> > 5. When Windows release is done, merge back into master and develop.
>> >
>> > If Windows gets enough testing this week where we'd feel comfortable
>> > with a release, then we could skip 4 and 5 of course.
>> >
>> > How's that for a game plan?
>> >
>> > steven
>> >
>> >
>> > [1] -
>> > https://github.com/csound/csound/commit/aa43ac375c1365fff4c4fa5194ffa9b639a2fc4c#commitcomment-25564649
>> >
>> >
>> > On Mon, Nov 13, 2017 at 1:07 PM, Michael Gogins
>> >  wrote:
>> >> Excuse me, no EARLIER than November 11...
>> >>
>> >> -----------------------------------------------------
>> >> Michael Gogins
>> >> Irreducible Productions
>> >> http://michaelgogins.tumblr.com
>> >> Michael dot Gogins at gmail dot com
>> >>
>> >>
>> >> On Mon, Nov 13, 2017 at 1:05 PM, Michael Gogins
>> >>  wrote:
>> >>> I would like to wait until we get some feedback on the stability of
>> >>> CsoundQt as packaged in the current installer built by AppVeyor (no
>> >>> later than November 11).
>> >>>
>> >>> Regards,
>> >>> Mike
>> >>>
>> >>> -----------------------------------------------------
>> >>> Michael Gogins
>> >>> Irreducible Productions
>> >>> http://michaelgogins.tumblr.com
>> >>> Michael dot Gogins at gmail dot com
>> >>>
>> >>>
>> >>> On Mon, Nov 13, 2017 at 12:24 PM, Victor Lazzarini
>> >>>  wrote:
>> >>>> I am ready to go at any point.
>> >>>>
>> >>>> Victor Lazzarini
>> >>>> Dean of Arts, Celtic Studies, and Philosophy
>> >>>> Maynooth University
>> >>>> Ireland
>> >>>>
>> >>>> On 13 Nov 2017, at 17:16, jpff  wrote:
>> >>>>
>> >>>> These are all ok now.  Do we have a plan?
>> >>>>
>> >>>> On Tue, 7 Nov 2017, jpff wrote:
>> >>>>
>> >>>> Major changes internally (corfiles) may need time for confidence
>> >>>>
>> >>>>
>> >>>> Release notes are not complete now
>> >>>>
>> >>>>
>> >>>> There are unexplained issues in DSSI/Ladspa.
>> >>>>
>> >>>>
>> >>>> otherwise I think this is way overdue
>> >>>>
>> >>>>
>

That is what I'm currently working on. It should happen like this:

1) we fork the Qt Installer Framework and modify a couple of files so
that we can use Github Releases as our hosting platform. I'm pondering
about using this project to host the abandoned frontends too.

2) we configure Travis and Appveyor in each project (core and frontends)
to build and publish the compressed installation files to Github
Releases once a tag is applied.

3) Travis and AppVeyor should also make a commit back to the repository,
updating the XML file the online installer is going to look for ->
Updates.xml.

I've seen github projects doing 2 and 3 separately, so my guess is that
it should work when combined.

Does this make sense to you?

Cheers.



On 14/11/17 16:42, Rory Walsh wrote:
> Hi guys, I just wanted to make sure we're all on the same page here. As far
> I understand, following discussions that arose from the Csound conference,
> the plan as we move forward is for the Csound project itself to stop
> building frontends completely, unless they are part of the official
> project. A new Csound installer branch will be set up (Guillermo is
> currently working on this). That installer will look after the packaging of
> Csound and all 3rd party frontends, retrieving them from their respective
> sites, github or otherwise. So after 6.10 CsoundQT will no longer even be
> part of the AppVeyor build. I really think this is a positive step, and one
> that should simplify the release process of Csound. Does this sound like a
> good summary of the situation?
>
>
>
> On 13 November 2017 at 21:13, Michael Gogins 
> wrote:
>
>> I'm OK with your plan, actually.
>>
>> After the release is fully complete, as you say, we can go back to
>> producing the producing the AppVeyor build with the develop branch and
>> test with that.
>>
>> Best,
>> Mke
>>
>>
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Mon, Nov 13, 2017 at 3:47 PM, Steven Yi  wrote:
>>> I mentioned on Github[1], but in case it was hidden, I'll raise the
>>> point that we've discussed using only stable releases of CsoundQt, got
>>> agreement to it from Tarmo, and were building the installer with
>>> stable CsoundQt but it was reverted back to develop again. I think
>>> testing CsoundQt beta code complicates testing core Csound, which
>>> should be a big enough task considering the move to VS.  Unless I'm
>>> missing something, stable CsoundQT should work with Csound 6.10 since
>>> the API has not changed in a breaking way, yes?  In other words, I
>>> don't understand the value in getting users to test both a dev version
>>> of CsoundQt and our Csound release candidate at the same time. From
>>> what I see, if I test the installer with with a stable CsoundQt and
>>> see a change in behavior, I can guess with some confidence that the
>>> source of the problem is Csound.  But with dev CsoundQt and release
>>> candidate Csound, I'll have to guess if its a CsoundQt problem or
>>> Csound one. (And couldn't CsoundQt dev build users just install that
>>> on their own to test?)
>>>
>>> Also, I'm pretty sure CsoundQt in the Mac installer is the last
>>> stable, not dev. Shouldn't that be the same across platforms?
>>>
>>> That all said, I also think the Windows release needs further testing.
>>> Last I remember, I was able to use Blue with my own Windows Visual
>>> Studio build, but Michael had crashes with Blue and the Appveyor
>>> Windows build. I'm getting through some other work today but I am
>>> planning to spend time tomorrow (Tuesday) on Windows testing (local VS
>>> build, AppVeyor installer, with Blue, with CSD tests, API, etc.).
>>>
>>> However, I'm bothered by the amount of time necessary to resolve
>>> testing on Windows. (BTW: I'm not sure I understand Michael's comments
>>> as it's already November 13th?).  I would like to suggest this:
>>>
>>> 1. Target Sunday, November 19th for a closing date for 6.10 code.
>>> This gives a fair amount of time to do testing this week. I think that
>>> should give enough time to get Rasmus' squinewave code integrated as
>>> well as look at bug 868 (https://github.com/csound/csound/issues/868),
>>> Thorin's reported issue dealing with live coding and schedule.
>>> 2. I'll go ahead and do an update of coverity branch in a moment and
>>> we can try to update regularly this week to catch any last minute
>>> issues.
>>>
>>> On Sunday, we can do:
>>>
>>> 1. Create a release branch. Update version strings, etc. and build
>>> installers/release zips.
>>> 2. Do release for all platforms except Windows (Linux, OSX, iOS,
>> Android, WASM)
>>> 3. Finish release, code is merged into develop and master
>>> 4. Create hotfix branch for Windows release (i.e., 6.10.0_win).  The
>>> hotfix would here be branched from master.  This would mean Windows
>>> build testing could keep going and use only code from the release and
>>> no new development code.
>>> 5. When Windows release is done, merge back into master and develop.
>>>
>>> If Windows gets enough testing this week where we'd feel comfortable
>>> with a release, then we could skip 4 and 5 of course.
>>>
>>> How's that for a game plan?
>>>
>>> steven
>>>
>>>
>>> [1] - https://github.com/csound/csound/commit/
>> aa43ac375c1365fff4c4fa5194ffa9b639a2fc4c#commitcomment-25564649
>>>
>>> On Mon, Nov 13, 2017 at 1:07 PM, Michael Gogins
>>>  wrote:
>>>> Excuse me, no EARLIER than November 11...
>>>>
>>>> -----------------------------------------------------
>>>> Michael Gogins
>>>> Irreducible Productions
>>>> http://michaelgogins.tumblr.com
>>>> Michael dot Gogins at gmail dot com
>>>>
>>>>
>>>> On Mon, Nov 13, 2017 at 1:05 PM, Michael Gogins
>>>>  wrote:
>>>>> I would like to wait until we get some feedback on the stability of
>>>>> CsoundQt as packaged in the current installer built by AppVeyor (no
>>>>> later than November 11).
>>>>>
>>>>> Regards,
>>>>> Mike
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Mon, Nov 13, 2017 at 12:24 PM, Victor Lazzarini
>>>>>  wrote:
>>>>>> I am ready to go at any point.
>>>>>>
>>>>>> Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>>
>>>>>> On 13 Nov 2017, at 17:16, jpff  wrote:
>>>>>>
>>>>>> These are all ok now.  Do we have a plan?
>>>>>>
>>>>>> On Tue, 7 Nov 2017, jpff wrote:
>>>>>>
>>>>>> Major changes internally (corfiles) may need time for confidence
>>>>>>
>>>>>>
>>>>>> Release notes are not complete now
>>>>>>
>>>>>>
>>>>>> There are unexplained issues in DSSI/Ladspa.
>>>>>>
>>>>>>
>>>>>> otherwise I think this is way overdue
>>>>>>

Some of the Csound developers discussed this question at the Csound
Conference in Montevideo.

The consensus, as I recall it, was that some sort of front end is sort
of necessary as a default part of Csound. So in that sense it is the
Csound developers who decide. But they don't do the work on CsoundQt,
Tarmo does. (I have worked on putting HTML5 into CsounQt and getting
CsoundQt into the Windows installer, but I don't work on other
CsoundQt issues). So it makes sense for Tarmo to decide what's the
best way for CsoundQt to go since he is the real maintainer.

However, several developers expressed concern about the stability of
CsoundQt reflecting adverse experiences with students and users.
Insofar as there was any agreement about how to resolve this, it is to
produce different installers for different kinds of users. I think
what Guillermo is trying to do, if it works, will solve this problem.

My personal view is that there should very much be a default front end
that just "comes with Csound" so that new users can run examples and
get up to speed quickly and in a fun way. Realistically, CsoundQt has
filled this role, and filled it very well when it runs without
crashing. Assuming this to be the path, then building in one place is
simpler than building in two places, and fixing the crashes should
become a priority with some real testing.

Regards,
Mike




-----------------------------------------------------
Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com


On Tue, Nov 14, 2017 at 3:23 PM, Rory Walsh  wrote:
>> I think Tarmo, who is the main maintainer of CsoundQt, should decide
>> whether it remains as part of the AppVeyor build.
>
>
> I personally think it should be down to developers of Csound, not CsoundQT,
> to decide what's built as part of the Csound project. But then again, I'm
> not a Csound developer.
>
>>
>> As to the installer branch, I'm not making up my mind until I see that
>> the installer is a better experience for the users.
>
>
> This is fair. I think we all hope this is a positive step to the future but
> will need to see how it works out. I feel we need to make it work at all
> costs.
>
>
>
>>
>>
>> Regards,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Tue, Nov 14, 2017 at 2:42 PM, Rory Walsh  wrote:
>> > Hi guys, I just wanted to make sure we're all on the same page here. As
>> > far
>> > I understand, following discussions that arose from the Csound
>> > conference,
>> > the plan as we move forward is for the Csound project itself to stop
>> > building frontends completely, unless they are part of the official
>> > project.
>> > A new Csound installer branch will be set up (Guillermo is currently
>> > working
>> > on this). That installer will look after the packaging of Csound and all
>> > 3rd
>> > party frontends, retrieving them from their respective sites, github or
>> > otherwise. So after 6.10 CsoundQT will no longer even be part of the
>> > AppVeyor build. I really think this is a positive step, and one that
>> > should
>> > simplify the release process of Csound. Does this sound like a good
>> > summary
>> > of the situation?
>> >
>> >
>> >
>> > On 13 November 2017 at 21:13, Michael Gogins 
>> > wrote:
>> >>
>> >> I'm OK with your plan, actually.
>> >>
>> >> After the release is fully complete, as you say, we can go back to
>> >> producing the producing the AppVeyor build with the develop branch and
>> >> test with that.
>> >>
>> >> Best,
>> >> Mke
>> >>
>> >>
>> >>
>> >> -----------------------------------------------------
>> >> Michael Gogins
>> >> Irreducible Productions
>> >> http://michaelgogins.tumblr.com
>> >> Michael dot Gogins at gmail dot com
>> >>
>> >>
>> >> On Mon, Nov 13, 2017 at 3:47 PM, Steven Yi  wrote:
>> >> > I mentioned on Github[1], but in case it was hidden, I'll raise the
>> >> > point that we've discussed using only stable releases of CsoundQt,
>> >> > got
>> >> > agreement to it from Tarmo, and were building the installer with
>> >> > stable CsoundQt but it was reverted back to develop again. I think
>> >> > testing CsoundQt beta code complicates testing core Csound, which
>> >> > should be a big enough task considering the move to VS.  Unless I'm
>> >> > missing something, stable CsoundQT should work with Csound 6.10 since
>> >> > the API has not changed in a breaking way, yes?  In other words, I
>> >> > don't understand the value in getting users to test both a dev
>> >> > version
>> >> > of CsoundQt and our Csound release candidate at the same time. From
>> >> > what I see, if I test the installer with with a stable CsoundQt and
>> >> > see a change in behavior, I can guess with some confidence that the
>> >> > source of the problem is Csound.  But with dev CsoundQt and release
>> >> > candidate Csound, I'll have to guess if its a CsoundQt problem or
>> >> > Csound one. (And couldn't CsoundQt dev build users just install that
>> >> > on their own to test?)
>> >> >
>> >> > Also, I'm pretty sure CsoundQt in the Mac installer is the last
>> >> > stable, not dev. Shouldn't that be the same across platforms?
>> >> >
>> >> > That all said, I also think the Windows release needs further
>> >> > testing.
>> >> > Last I remember, I was able to use Blue with my own Windows Visual
>> >> > Studio build, but Michael had crashes with Blue and the Appveyor
>> >> > Windows build. I'm getting through some other work today but I am
>> >> > planning to spend time tomorrow (Tuesday) on Windows testing (local
>> >> > VS
>> >> > build, AppVeyor installer, with Blue, with CSD tests, API, etc.).
>> >> >
>> >> > However, I'm bothered by the amount of time necessary to resolve
>> >> > testing on Windows. (BTW: I'm not sure I understand Michael's
>> >> > comments
>> >> > as it's already November 13th?).  I would like to suggest this:
>> >> >
>> >> > 1. Target Sunday, November 19th for a closing date for 6.10 code.
>> >> > This gives a fair amount of time to do testing this week. I think
>> >> > that
>> >> > should give enough time to get Rasmus' squinewave code integrated as
>> >> > well as look at bug 868
>> >> > (https://github.com/csound/csound/issues/868),
>> >> > Thorin's reported issue dealing with live coding and schedule.
>> >> > 2. I'll go ahead and do an update of coverity branch in a moment and
>> >> > we can try to update regularly this week to catch any last minute
>> >> > issues.
>> >> >
>> >> > On Sunday, we can do:
>> >> >
>> >> > 1. Create a release branch. Update version strings, etc. and build
>> >> > installers/release zips.
>> >> > 2. Do release for all platforms except Windows (Linux, OSX, iOS,
>> >> > Android, WASM)
>> >> > 3. Finish release, code is merged into develop and master
>> >> > 4. Create hotfix branch for Windows release (i.e., 6.10.0_win).  The
>> >> > hotfix would here be branched from master.  This would mean Windows
>> >> > build testing could keep going and use only code from the release and
>> >> > no new development code.
>> >> > 5. When Windows release is done, merge back into master and develop.
>> >> >
>> >> > If Windows gets enough testing this week where we'd feel comfortable
>> >> > with a release, then we could skip 4 and 5 of course.
>> >> >
>> >> > How's that for a game plan?
>> >> >
>> >> > steven
>> >> >
>> >> >
>> >> > [1] -
>> >> >
>> >> > https://github.com/csound/csound/commit/aa43ac375c1365fff4c4fa5194ffa9b639a2fc4c#commitcomment-25564649
>> >> >
>> >> >
>> >> > On Mon, Nov 13, 2017 at 1:07 PM, Michael Gogins
>> >> >  wrote:
>> >> >> Excuse me, no EARLIER than November 11...
>> >> >>
>> >> >> -----------------------------------------------------
>> >> >> Michael Gogins
>> >> >> Irreducible Productions
>> >> >> http://michaelgogins.tumblr.com
>> >> >> Michael dot Gogins at gmail dot com
>> >> >>
>> >> >>
>> >> >> On Mon, Nov 13, 2017 at 1:05 PM, Michael Gogins
>> >> >>  wrote:
>> >> >>> I would like to wait until we get some feedback on the stability of
>> >> >>> CsoundQt as packaged in the current installer built by AppVeyor (no
>> >> >>> later than November 11).
>> >> >>>
>> >> >>> Regards,
>> >> >>> Mike
>> >> >>>
>> >> >>> -----------------------------------------------------
>> >> >>> Michael Gogins
>> >> >>> Irreducible Productions
>> >> >>> http://michaelgogins.tumblr.com
>> >> >>> Michael dot Gogins at gmail dot com
>> >> >>>
>> >> >>>
>> >> >>> On Mon, Nov 13, 2017 at 12:24 PM, Victor Lazzarini
>> >> >>>  wrote:
>> >> >>>> I am ready to go at any point.
>> >> >>>>
>> >> >>>> Victor Lazzarini
>> >> >>>> Dean of Arts, Celtic Studies, and Philosophy
>> >> >>>> Maynooth University
>> >> >>>> Ireland
>> >> >>>>
>> >> >>>> On 13 Nov 2017, at 17:16, jpff  wrote:
>> >> >>>>
>> >> >>>> These are all ok now.  Do we have a plan?
>> >> >>>>
>> >> >>>> On Tue, 7 Nov 2017, jpff wrote:
>> >> >>>>
>> >> >>>> Major changes internally (corfiles) may need time for confidence
>> >> >>>>
>> >> >>>>
>> >> >>>> Release notes are not complete now
>> >> >>>>
>> >> >>>>
>> >> >>>> There are unexplained issues in DSSI/Ladspa.
>> >> >>>>
>> >> >>>>
>> >> >>>> otherwise I think this is way overdue
>> >> >>>>
>> >> >>>>
>> >
>> >
>

Indeed, the online installer would solve the problem and there shouldn't
be a need to have anything related to CsoundQt in the Csound repo.

However, if you look at the attached picture a new question arises:
Should we have all, any or none of the interfaces checked by default?



On 14/11/17 18:05, Michael Gogins wrote:
> Some of the Csound developers discussed this question at the Csound
> Conference in Montevideo.
>
> The consensus, as I recall it, was that some sort of front end is sort
> of necessary as a default part of Csound. So in that sense it is the
> Csound developers who decide. But they don't do the work on CsoundQt,
> Tarmo does. (I have worked on putting HTML5 into CsounQt and getting
> CsoundQt into the Windows installer, but I don't work on other
> CsoundQt issues). So it makes sense for Tarmo to decide what's the
> best way for CsoundQt to go since he is the real maintainer.
>
> However, several developers expressed concern about the stability of
> CsoundQt reflecting adverse experiences with students and users.
> Insofar as there was any agreement about how to resolve this, it is to
> produce different installers for different kinds of users. I think
> what Guillermo is trying to do, if it works, will solve this problem.
>
> My personal view is that there should very much be a default front end
> that just "comes with Csound" so that new users can run examples and
> get up to speed quickly and in a fun way. Realistically, CsoundQt has
> filled this role, and filled it very well when it runs without
> crashing. Assuming this to be the path, then building in one place is
> simpler than building in two places, and fixing the crashes should
> become a priority with some real testing.
>
> Regards,
> Mike
>
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Tue, Nov 14, 2017 at 3:23 PM, Rory Walsh  wrote:
>>> I think Tarmo, who is the main maintainer of CsoundQt, should decide
>>> whether it remains as part of the AppVeyor build.
>>
>> I personally think it should be down to developers of Csound, not CsoundQT,
>> to decide what's built as part of the Csound project. But then again, I'm
>> not a Csound developer.
>>
>>> As to the installer branch, I'm not making up my mind until I see that
>>> the installer is a better experience for the users.
>>
>> This is fair. I think we all hope this is a positive step to the future but
>> will need to see how it works out. I feel we need to make it work at all
>> costs.
>>
>>
>>
>>>
>>> Regards,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> On Tue, Nov 14, 2017 at 2:42 PM, Rory Walsh  wrote:
>>>> Hi guys, I just wanted to make sure we're all on the same page here. As
>>>> far
>>>> I understand, following discussions that arose from the Csound
>>>> conference,
>>>> the plan as we move forward is for the Csound project itself to stop
>>>> building frontends completely, unless they are part of the official
>>>> project.
>>>> A new Csound installer branch will be set up (Guillermo is currently
>>>> working
>>>> on this). That installer will look after the packaging of Csound and all
>>>> 3rd
>>>> party frontends, retrieving them from their respective sites, github or
>>>> otherwise. So after 6.10 CsoundQT will no longer even be part of the
>>>> AppVeyor build. I really think this is a positive step, and one that
>>>> should
>>>> simplify the release process of Csound. Does this sound like a good
>>>> summary
>>>> of the situation?
>>>>
>>>>
>>>>
>>>> On 13 November 2017 at 21:13, Michael Gogins 
>>>> wrote:
>>>>> I'm OK with your plan, actually.
>>>>>
>>>>> After the release is fully complete, as you say, we can go back to
>>>>> producing the producing the AppVeyor build with the develop branch and
>>>>> test with that.
>>>>>
>>>>> Best,
>>>>> Mke
>>>>>
>>>>>
>>>>>
>>>>> -----------------------------------------------------
>>>>> Michael Gogins
>>>>> Irreducible Productions
>>>>> http://michaelgogins.tumblr.com
>>>>> Michael dot Gogins at gmail dot com
>>>>>
>>>>>
>>>>> On Mon, Nov 13, 2017 at 3:47 PM, Steven Yi  wrote:
>>>>>> I mentioned on Github[1], but in case it was hidden, I'll raise the
>>>>>> point that we've discussed using only stable releases of CsoundQt,
>>>>>> got
>>>>>> agreement to it from Tarmo, and were building the installer with
>>>>>> stable CsoundQt but it was reverted back to develop again. I think
>>>>>> testing CsoundQt beta code complicates testing core Csound, which
>>>>>> should be a big enough task considering the move to VS.  Unless I'm
>>>>>> missing something, stable CsoundQT should work with Csound 6.10 since
>>>>>> the API has not changed in a breaking way, yes?  In other words, I
>>>>>> don't understand the value in getting users to test both a dev
>>>>>> version
>>>>>> of CsoundQt and our Csound release candidate at the same time. From
>>>>>> what I see, if I test the installer with with a stable CsoundQt and
>>>>>> see a change in behavior, I can guess with some confidence that the
>>>>>> source of the problem is Csound.  But with dev CsoundQt and release
>>>>>> candidate Csound, I'll have to guess if its a CsoundQt problem or
>>>>>> Csound one. (And couldn't CsoundQt dev build users just install that
>>>>>> on their own to test?)
>>>>>>
>>>>>> Also, I'm pretty sure CsoundQt in the Mac installer is the last
>>>>>> stable, not dev. Shouldn't that be the same across platforms?
>>>>>>
>>>>>> That all said, I also think the Windows release needs further
>>>>>> testing.
>>>>>> Last I remember, I was able to use Blue with my own Windows Visual
>>>>>> Studio build, but Michael had crashes with Blue and the Appveyor
>>>>>> Windows build. I'm getting through some other work today but I am
>>>>>> planning to spend time tomorrow (Tuesday) on Windows testing (local
>>>>>> VS
>>>>>> build, AppVeyor installer, with Blue, with CSD tests, API, etc.).
>>>>>>
>>>>>> However, I'm bothered by the amount of time necessary to resolve
>>>>>> testing on Windows. (BTW: I'm not sure I understand Michael's
>>>>>> comments
>>>>>> as it's already November 13th?).  I would like to suggest this:
>>>>>>
>>>>>> 1. Target Sunday, November 19th for a closing date for 6.10 code.
>>>>>> This gives a fair amount of time to do testing this week. I think
>>>>>> that
>>>>>> should give enough time to get Rasmus' squinewave code integrated as
>>>>>> well as look at bug 868
>>>>>> (https://github.com/csound/csound/issues/868),
>>>>>> Thorin's reported issue dealing with live coding and schedule.
>>>>>> 2. I'll go ahead and do an update of coverity branch in a moment and
>>>>>> we can try to update regularly this week to catch any last minute
>>>>>> issues.
>>>>>>
>>>>>> On Sunday, we can do:
>>>>>>
>>>>>> 1. Create a release branch. Update version strings, etc. and build
>>>>>> installers/release zips.
>>>>>> 2. Do release for all platforms except Windows (Linux, OSX, iOS,
>>>>>> Android, WASM)
>>>>>> 3. Finish release, code is merged into develop and master
>>>>>> 4. Create hotfix branch for Windows release (i.e., 6.10.0_win).  The
>>>>>> hotfix would here be branched from master.  This would mean Windows
>>>>>> build testing could keep going and use only code from the release and
>>>>>> no new development code.
>>>>>> 5. When Windows release is done, merge back into master and develop.
>>>>>>
>>>>>> If Windows gets enough testing this week where we'd feel comfortable
>>>>>> with a release, then we could skip 4 and 5 of course.
>>>>>>
>>>>>> How's that for a game plan?
>>>>>>
>>>>>> steven
>>>>>>
>>>>>>
>>>>>> [1] -
>>>>>>
>>>>>> https://github.com/csound/csound/commit/aa43ac375c1365fff4c4fa5194ffa9b639a2fc4c#commitcomment-25564649
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 13, 2017 at 1:07 PM, Michael Gogins
>>>>>>  wrote:
>>>>>>> Excuse me, no EARLIER than November 11...
>>>>>>>
>>>>>>> -----------------------------------------------------
>>>>>>> Michael Gogins
>>>>>>> Irreducible Productions
>>>>>>> http://michaelgogins.tumblr.com
>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 13, 2017 at 1:05 PM, Michael Gogins
>>>>>>>  wrote:
>>>>>>>> I would like to wait until we get some feedback on the stability of
>>>>>>>> CsoundQt as packaged in the current installer built by AppVeyor (no
>>>>>>>> later than November 11).
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> -----------------------------------------------------
>>>>>>>> Michael Gogins
>>>>>>>> Irreducible Productions
>>>>>>>> http://michaelgogins.tumblr.com
>>>>>>>> Michael dot Gogins at gmail dot com
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 13, 2017 at 12:24 PM, Victor Lazzarini
>>>>>>>>  wrote:
>>>>>>>>> I am ready to go at any point.
>>>>>>>>>
>>>>>>>>> Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>> Maynooth University
>>>>>>>>> Ireland
>>>>>>>>>
>>>>>>>>> On 13 Nov 2017, at 17:16, jpff  wrote:
>>>>>>>>>
>>>>>>>>> These are all ok now.  Do we have a plan?
>>>>>>>>>
>>>>>>>>> On Tue, 7 Nov 2017, jpff wrote:
>>>>>>>>>
>>>>>>>>> Major changes internally (corfiles) may need time for confidence
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Release notes are not complete now
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> There are unexplained issues in DSSI/Ladspa.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> otherwise I think this is way overdue
>>>>>>>>>
>>>>>>>>>
>>>>
>>