Hi All,

We had discussed getting the release branch started today but I think
there's a few open loops to close:

1. Windows: Static-linking for libsndfile: this is done but there's
one issue left with CsoundQt missing from the installer.  A fix is in
and it's being built on AppVeyor now.  Testing of the previous Csound
installer though passed my own light testing, but it would be good to
get last minute checks by other users and developers using the API.
(I'm looking into this.)

2. vst4cs: this is reported to cause a crash with Blue just by its
presence in OPCODEDIR.  (Reported by Menno on Linux).  I suspect this
may also cause crashes for other Csound API-based programs.  (Awaiting
Michael to fix.)

3. Realtime branch: This is work for the --realtime, particularly
being driven by support for Bela at the moment, happening in the
feature/realtime branch.  I think it's gone back and forth whether
this is will go into 6.10 or not.  (Needs Victor to comment.)

4. Android: Realtime input seems to have problems. I saw the problem
here on my Moto G4 and Jacques reported it on Pixel. I think both are
64-bit CPUs, which may be a factor.  (I'm looking into this.)

1 and 4 should hopefully get done today.  I think we should look at
Sunday or Monday now to get these resolved and to start the branch.

Please reply here if there are any other issues found.

Thanks,

Hi All,

We had discussed getting the release branch started today but I think
there's a few open loops to close:

1. Windows: Static-linking for libsndfile: this is done but there's
one issue left with CsoundQt missing from the installer.  A fix is in
and it's being built on AppVeyor now.  Testing of the previous Csound
installer though passed my own light testing, but it would be good to
get last minute checks by other users and developers using the API.
(I'm looking into this.)

2. vst4cs: this is reported to cause a crash with Blue just by its
presence in OPCODEDIR.  (Reported by Menno on Linux).  I suspect this
may also cause crashes for other Csound API-based programs.  (Awaiting
Michael to fix.)

3. Realtime branch: This is work for the --realtime, particularly
being driven by support for Bela at the moment, happening in the
feature/realtime branch.  I think it's gone back and forth whether
this is will go into 6.10 or not.  (Needs Victor to comment.)

4. Android: Realtime input seems to have problems. I saw the problem
here on my Moto G4 and Jacques reported it on Pixel. I think both are
64-bit CPUs, which may be a factor.  (I'm looking into this.)

1 and 4 should hopefully get done today.  I think we should look at
Sunday or Monday now to get these resolved and to start the branch.

Please reply here if there are any other issues found.

Thanks,
steven

Regarding #1 (Windows Installer, CsoundQt): CsoundQt is building and
is included in the installer.  I can run it and it shows Csound output
when running an example. DrunkWalk.csd from Iain's collection runs
fine in realtime.  The installer tested was:

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

I think #1 is then finished as CsoundQt is now in the installer.
(There are a couple of other new issues however, see below.)

Regarding #2: I found that CsoundQt on Windows hung whenever rendering
was stopped.  Deleting vst4cs.dll from the opcode dir fixed that. I
suspect that it is the same issue reported by Menno and Rory, and this
should make the problem with vst4cs easy to test.


New issues:

#5 - CsoundQt: VirtualKeyboard doesn't seem to work. This has to do
with the one built by AppVeyor.  If I use the 0.9.5 version released
by Tarmo, VirtualKeyboard works fine.  Since this has to do with
CsoundQt, I'll leave it to Michael.

#6 - I noticed that the HTML manual does not appear in CsoundQt's
opcode help.  This was reported earlier when users tested an earlier
version of the installer.  Since this is related to CsoundQt, I will
leave it Michael to solve.




On Fri, Dec 8, 2017 at 12:31 PM, Michael Gogins
 wrote:
> I will look at the vst4cs issue this evening or tomorrow.
>
> Best, Mike
>
> On Dec 8, 2017 11:58 AM, "Rory Walsh"  wrote:
>>
>> I too was having issues with Cabbage crashing on exit due to the present
>> of vst4cs in the opcodes dir. I will check again tonight and report back.
>>
>> On 8 December 2017 at 16:48, Steven Yi  wrote:
>>>
>>> Hi All,
>>>
>>> We had discussed getting the release branch started today but I think
>>> there's a few open loops to close:
>>>
>>> 1. Windows: Static-linking for libsndfile: this is done but there's
>>> one issue left with CsoundQt missing from the installer.  A fix is in
>>> and it's being built on AppVeyor now.  Testing of the previous Csound
>>> installer though passed my own light testing, but it would be good to
>>> get last minute checks by other users and developers using the API.
>>> (I'm looking into this.)
>>>
>>> 2. vst4cs: this is reported to cause a crash with Blue just by its
>>> presence in OPCODEDIR.  (Reported by Menno on Linux).  I suspect this
>>> may also cause crashes for other Csound API-based programs.  (Awaiting
>>> Michael to fix.)
>>>
>>> 3. Realtime branch: This is work for the --realtime, particularly
>>> being driven by support for Bela at the moment, happening in the
>>> feature/realtime branch.  I think it's gone back and forth whether
>>> this is will go into 6.10 or not.  (Needs Victor to comment.)
>>>
>>> 4. Android: Realtime input seems to have problems. I saw the problem
>>> here on my Moto G4 and Jacques reported it on Pixel. I think both are
>>> 64-bit CPUs, which may be a factor.  (I'm looking into this.)
>>>
>>> 1 and 4 should hopefully get done today.  I think we should look at
>>> Sunday or Monday now to get these resolved and to start the branch.
>>>
>>> Please reply here if there are any other issues found.
>>>
>>> Thanks,
>>> steven
>>
>>

Regarding #4: I'm having some problems with logcat at the moment, but
what I've found so far is that if I set nchnls_i=1 in harmonizer.csd
and ping_pong_delay.csd in the example project, those examples will
work though with distorted sound. (Otherwise, those files would
default to use the same nchnls_i as nchnls, which is 2). I see
multiple problems here:

1. bqRecorderCallback looks to be using GetNchnls, while rtopensl.c
was changed to  GetNchnls_i in the openSL device opening.

2. Changes related to input happened in openSL last year (see last
four commits to the file
https://github.com/csound/csound/commits/develop/android/CsoundAndroid/jni/rtopensl.c).
The last four commits are done by Michael and Victor.

What I suspect: on devices that were used for testing when the changes
happened, stereo audio input was possible, but it is not possible on
other devices (like the Google Pixel and MotoG4). This might be
related to device but it may also be related to OS version too. I've
had this MotoG4 for about 11 months and I would have used this when we
did the last release. The only difference I can think of is that my OS
version upgraded to 7.0 since the last Csound release.

Also, prior to the last four commits on rtopensl.c, we defaulted to
only opening mono input.  This seems to work across all devices, or at
least, seemed to work for years since we first started the Csound for
Android SDK.

I am not sure what should happen here. Since this seems to stem from
changes from Victor and Michael, perhaps they could comment on this
situation.




On Fri, Dec 8, 2017 at 2:54 PM, Rory Walsh  wrote:
> I'll wait for Mike to look into issue number 2 before doing a completely new
> build of Cabbage. If CsoundQT is still crashing I expect Cabbage will too.
> Mike, let me know when you have something for me to test. Thanks.
>
> On 8 December 2017 at 18:24, Steven Yi  wrote:
>>
>> Regarding #1 (Windows Installer, CsoundQt): CsoundQt is building and
>> is included in the installer.  I can run it and it shows Csound output
>> when running an example. DrunkWalk.csd from Iain's collection runs
>> fine in realtime.  The installer tested was:
>>
>> https://ci.appveyor.com/project/csound/csound/build/6.10.968/artifacts
>>
>> I think #1 is then finished as CsoundQt is now in the installer.
>> (There are a couple of other new issues however, see below.)
>>
>> Regarding #2: I found that CsoundQt on Windows hung whenever rendering
>> was stopped.  Deleting vst4cs.dll from the opcode dir fixed that. I
>> suspect that it is the same issue reported by Menno and Rory, and this
>> should make the problem with vst4cs easy to test.
>>
>>
>> New issues:
>>
>> #5 - CsoundQt: VirtualKeyboard doesn't seem to work. This has to do
>> with the one built by AppVeyor.  If I use the 0.9.5 version released
>> by Tarmo, VirtualKeyboard works fine.  Since this has to do with
>> CsoundQt, I'll leave it to Michael.
>>
>> #6 - I noticed that the HTML manual does not appear in CsoundQt's
>> opcode help.  This was reported earlier when users tested an earlier
>> version of the installer.  Since this is related to CsoundQt, I will
>> leave it Michael to solve.
>>
>>
>>
>>
>> On Fri, Dec 8, 2017 at 12:31 PM, Michael Gogins
>>  wrote:
>> > I will look at the vst4cs issue this evening or tomorrow.
>> >
>> > Best, Mike
>> >
>> > On Dec 8, 2017 11:58 AM, "Rory Walsh"  wrote:
>> >>
>> >> I too was having issues with Cabbage crashing on exit due to the
>> >> present
>> >> of vst4cs in the opcodes dir. I will check again tonight and report
>> >> back.
>> >>
>> >> On 8 December 2017 at 16:48, Steven Yi  wrote:
>> >>>
>> >>> Hi All,
>> >>>
>> >>> We had discussed getting the release branch started today but I think
>> >>> there's a few open loops to close:
>> >>>
>> >>> 1. Windows: Static-linking for libsndfile: this is done but there's
>> >>> one issue left with CsoundQt missing from the installer.  A fix is in
>> >>> and it's being built on AppVeyor now.  Testing of the previous Csound
>> >>> installer though passed my own light testing, but it would be good to
>> >>> get last minute checks by other users and developers using the API.
>> >>> (I'm looking into this.)
>> >>>
>> >>> 2. vst4cs: this is reported to cause a crash with Blue just by its
>> >>> presence in OPCODEDIR.  (Reported by Menno on Linux).  I suspect this
>> >>> may also cause crashes for other Csound API-based programs.  (Awaiting
>> >>> Michael to fix.)
>> >>>
>> >>> 3. Realtime branch: This is work for the --realtime, particularly
>> >>> being driven by support for Bela at the moment, happening in the
>> >>> feature/realtime branch.  I think it's gone back and forth whether
>> >>> this is will go into 6.10 or not.  (Needs Victor to comment.)
>> >>>
>> >>> 4. Android: Realtime input seems to have problems. I saw the problem
>> >>> here on my Moto G4 and Jacques reported it on Pixel. I think both are
>> >>> 64-bit CPUs, which may be a factor.  (I'm looking into this.)
>> >>>
>> >>> 1 and 4 should hopefully get done today.  I think we should look at
>> >>> Sunday or Monday now to get these resolved and to start the branch.
>> >>>
>> >>> Please reply here if there are any other issues found.
>> >>>
>> >>> Thanks,
>> >>> steven
>> >>
>> >>
>> >
>

Hi Tarmo:

For missing DLL, does it show a kind of message or something?  And is
this for CsoundQt only, or happen when running commandline csound?  I
only have Windows 10 here so I am not sure what I can do here to test.

On my system, when I went to use the installer it installed into
Csound_x64.  I don't know if that's because I had a previous install
already.  Perhaps Michael would know about this as it looks like
something related to artifact name changing he discussed here.

Thanks,
steven

On Fri, Dec 8, 2017 at 4:41 PM, Tarmo Johannes  wrote:
> Hi,
>
>
> about #1:
>
> I tried to install this version from AppVeyor on a virtual machine running
> Windows 8.1 but could not get CsoundQt running there - first it missed some
> dll files: (maybe it is a problem of my installation but for any cas I
> report here:
> api-ms-win-crt-heap-l1-1-0.dll
> api-ms-win-crt-string-l1-1-0.dll
> api-ms-win-crt-runtime-l1-1-0.dll
> api-ms-win-crt-math-l1-1-0.dll
>
> Unfortunatley it did not start wiht message "This program is not able to
> start correctly". Most likely it the virtual machine, don't take it too
> seriously. I will try to test in on a real Windows 10 later.
>
> I noticed that the installation path of Csound has changed - before it was
> Csounx64, now csound-windows-x64. Is it meant like this? That's why the
> manual was not found. It is possible to set the manual's path in CsoundQt
> options but if the installation path stays like that, I would do something
> in CsoundQt code to look for that as well.
>
> tarmo
>
>
> 2017-12-08 20:24 GMT+02:00 Steven Yi :
>>
>> Regarding #1 (Windows Installer, CsoundQt): CsoundQt is building and
>> is included in the installer.  I can run it and it shows Csound output
>> when running an example. DrunkWalk.csd from Iain's collection runs
>> fine in realtime.  The installer tested was:
>>
>> https://ci.appveyor.com/project/csound/csound/build/6.10.968/artifacts
>>
>> I think #1 is then finished as CsoundQt is now in the installer.
>> (There are a couple of other new issues however, see below.)
>>
>> Regarding #2: I found that CsoundQt on Windows hung whenever rendering
>> was stopped.  Deleting vst4cs.dll from the opcode dir fixed that. I
>> suspect that it is the same issue reported by Menno and Rory, and this
>> should make the problem with vst4cs easy to test.
>>
>>
>> New issues:
>>
>> #5 - CsoundQt: VirtualKeyboard doesn't seem to work. This has to do
>> with the one built by AppVeyor.  If I use the 0.9.5 version released
>> by Tarmo, VirtualKeyboard works fine.  Since this has to do with
>> CsoundQt, I'll leave it to Michael.
>>
>> #6 - I noticed that the HTML manual does not appear in CsoundQt's
>> opcode help.  This was reported earlier when users tested an earlier
>> version of the installer.  Since this is related to CsoundQt, I will
>> leave it Michael to solve.
>>
>>
>>
>>
>> On Fri, Dec 8, 2017 at 12:31 PM, Michael Gogins
>>  wrote:
>> > I will look at the vst4cs issue this evening or tomorrow.
>> >
>> > Best, Mike
>> >
>> > On Dec 8, 2017 11:58 AM, "Rory Walsh"  wrote:
>> >>
>> >> I too was having issues with Cabbage crashing on exit due to the
>> >> present
>> >> of vst4cs in the opcodes dir. I will check again tonight and report
>> >> back.
>> >>
>> >> On 8 December 2017 at 16:48, Steven Yi  wrote:
>> >>>
>> >>> Hi All,
>> >>>
>> >>> We had discussed getting the release branch started today but I think
>> >>> there's a few open loops to close:
>> >>>
>> >>> 1. Windows: Static-linking for libsndfile: this is done but there's
>> >>> one issue left with CsoundQt missing from the installer.  A fix is in
>> >>> and it's being built on AppVeyor now.  Testing of the previous Csound
>> >>> installer though passed my own light testing, but it would be good to
>> >>> get last minute checks by other users and developers using the API.
>> >>> (I'm looking into this.)
>> >>>
>> >>> 2. vst4cs: this is reported to cause a crash with Blue just by its
>> >>> presence in OPCODEDIR.  (Reported by Menno on Linux).  I suspect this
>> >>> may also cause crashes for other Csound API-based programs.  (Awaiting
>> >>> Michael to fix.)
>> >>>
>> >>> 3. Realtime branch: This is work for the --realtime, particularly
>> >>> being driven by support for Bela at the moment, happening in the
>> >>> feature/realtime branch.  I think it's gone back and forth whether
>> >>> this is will go into 6.10 or not.  (Needs Victor to comment.)
>> >>>
>> >>> 4. Android: Realtime input seems to have problems. I saw the problem
>> >>> here on my Moto G4 and Jacques reported it on Pixel. I think both are
>> >>> 64-bit CPUs, which may be a factor.  (I'm looking into this.)
>> >>>
>> >>> 1 and 4 should hopefully get done today.  I think we should look at
>> >>> Sunday or Monday now to get these resolved and to start the branch.
>> >>>
>> >>> Please reply here if there are any other issues found.
>> >>>
>> >>> Thanks,
>> >>> steven
>> >>
>> >>
>> >
>

HI Tarmo,

As mentioned in another thread, having a dynamically linked libsndfile
for Csound itself causes a major problem when used from API apps that
link to a different C runtime than what was used for libsndfile. (As
documented on libsndfile's API.)  For Csound 6.09 and earlier, where
we used MinGW, libsndfile and dependencies were statically linked. In
the VS build, it was initially dynamically linked, I discovered the
problem when running from Blue, and thus modified to use static
libsndfile.  The csound library now works from API and commandline,
regardless of what C runtime was linked to the host program.

For CsoundQt, because I switched to static libsndfile for Csound, I
set the CsoundQt being built on AppVeyor to the same. Does CsoundQt
specifically require dynamic linking to libsndfile?

I just uninstalled Csound6 to start from a clean slate. Using the
installer, it did indeed ask to install into "c:\Program
Files\csound-windows-x64".  So that looks to be a problem. I have no
libsndfile.dll but CsoundQt is still running (but Virtual Keyboard is
still broken).

steven

On Fri, Dec 8, 2017 at 5:31 PM, Tarmo Johannes  wrote:
> Hello,
>
> Another strange thing I noticed -  the bin folder is missing
> libsndfile-1.dll
> Is it actually necessary? i guess when Csound is compiled against the MSVC
> .lib library of sndfile, it might  not be needed.
>
> i noticed the probelm when I tried to start CsoundQt 0.9.5 from  zip file by
> CsoundQt release. It  was built against Csound 6.09 and via some dpendencies
> requires libsndfile.dll  When I copied the file from Csound 6.09
> installation to folder of CsoundQt (mine), then it started fine.
>
> This problem happens only when user erases or removes the previous
> installation, otherwise libsndfile-1.dll just stays there.  Thus it is not
> really a bug, just good to know.
>
> t
>
>
>
>
>
> 2017-12-09 0:07 GMT+02:00 Steven Yi :
>>
>> Hi Tarmo:
>>
>> For missing DLL, does it show a kind of message or something?  And is
>> this for CsoundQt only, or happen when running commandline csound?  I
>> only have Windows 10 here so I am not sure what I can do here to test.
>>
>> On my system, when I went to use the installer it installed into
>> Csound_x64.  I don't know if that's because I had a previous install
>> already.  Perhaps Michael would know about this as it looks like
>> something related to artifact name changing he discussed here.
>>
>> Thanks,
>> steven
>>
>> On Fri, Dec 8, 2017 at 4:41 PM, Tarmo Johannes  wrote:
>> > Hi,
>> >
>> >
>> > about #1:
>> >
>> > I tried to install this version from AppVeyor on a virtual machine
>> > running
>> > Windows 8.1 but could not get CsoundQt running there - first it missed
>> > some
>> > dll files: (maybe it is a problem of my installation but for any cas I
>> > report here:
>> > api-ms-win-crt-heap-l1-1-0.dll
>> > api-ms-win-crt-string-l1-1-0.dll
>> > api-ms-win-crt-runtime-l1-1-0.dll
>> > api-ms-win-crt-math-l1-1-0.dll
>> >
>> > Unfortunatley it did not start wiht message "This program is not able to
>> > start correctly". Most likely it the virtual machine, don't take it too
>> > seriously. I will try to test in on a real Windows 10 later.
>> >
>> > I noticed that the installation path of Csound has changed - before it
>> > was
>> > Csounx64, now csound-windows-x64. Is it meant like this? That's why the
>> > manual was not found. It is possible to set the manual's path in
>> > CsoundQt
>> > options but if the installation path stays like that, I would do
>> > something
>> > in CsoundQt code to look for that as well.
>> >
>> > tarmo
>> >
>> >
>> > 2017-12-08 20:24 GMT+02:00 Steven Yi :
>> >>
>> >> Regarding #1 (Windows Installer, CsoundQt): CsoundQt is building and
>> >> is included in the installer.  I can run it and it shows Csound output
>> >> when running an example. DrunkWalk.csd from Iain's collection runs
>> >> fine in realtime.  The installer tested was:
>> >>
>> >> https://ci.appveyor.com/project/csound/csound/build/6.10.968/artifacts
>> >>
>> >> I think #1 is then finished as CsoundQt is now in the installer.
>> >> (There are a couple of other new issues however, see below.)
>> >>
>> >> Regarding #2: I found that CsoundQt on Windows hung whenever rendering
>> >> was stopped.  Deleting vst4cs.dll from the opcode dir fixed that. I
>> >> suspect that it is the same issue reported by Menno and Rory, and this
>> >> should make the problem with vst4cs easy to test.
>> >>
>> >>
>> >> New issues:
>> >>
>> >> #5 - CsoundQt: VirtualKeyboard doesn't seem to work. This has to do
>> >> with the one built by AppVeyor.  If I use the 0.9.5 version released
>> >> by Tarmo, VirtualKeyboard works fine.  Since this has to do with
>> >> CsoundQt, I'll leave it to Michael.
>> >>
>> >> #6 - I noticed that the HTML manual does not appear in CsoundQt's
>> >> opcode help.  This was reported earlier when users tested an earlier
>> >> version of the installer.  Since this is related to CsoundQt, I will
>> >> leave it Michael to solve.
>> >>
>> >>
>> >>
>> >>
>> >> On Fri, Dec 8, 2017 at 12:31 PM, Michael Gogins
>> >>  wrote:
>> >> > I will look at the vst4cs issue this evening or tomorrow.
>> >> >
>> >> > Best, Mike
>> >> >
>> >> > On Dec 8, 2017 11:58 AM, "Rory Walsh"  wrote:
>> >> >>
>> >> >> I too was having issues with Cabbage crashing on exit due to the
>> >> >> present
>> >> >> of vst4cs in the opcodes dir. I will check again tonight and report
>> >> >> back.
>> >> >>
>> >> >> On 8 December 2017 at 16:48, Steven Yi  wrote:
>> >> >>>
>> >> >>> Hi All,
>> >> >>>
>> >> >>> We had discussed getting the release branch started today but I
>> >> >>> think
>> >> >>> there's a few open loops to close:
>> >> >>>
>> >> >>> 1. Windows: Static-linking for libsndfile: this is done but there's
>> >> >>> one issue left with CsoundQt missing from the installer.  A fix is
>> >> >>> in
>> >> >>> and it's being built on AppVeyor now.  Testing of the previous
>> >> >>> Csound
>> >> >>> installer though passed my own light testing, but it would be good
>> >> >>> to
>> >> >>> get last minute checks by other users and developers using the API.
>> >> >>> (I'm looking into this.)
>> >> >>>
>> >> >>> 2. vst4cs: this is reported to cause a crash with Blue just by its
>> >> >>> presence in OPCODEDIR.  (Reported by Menno on Linux).  I suspect
>> >> >>> this
>> >> >>> may also cause crashes for other Csound API-based programs.
>> >> >>> (Awaiting
>> >> >>> Michael to fix.)
>> >> >>>
>> >> >>> 3. Realtime branch: This is work for the --realtime, particularly
>> >> >>> being driven by support for Bela at the moment, happening in the
>> >> >>> feature/realtime branch.  I think it's gone back and forth whether
>> >> >>> this is will go into 6.10 or not.  (Needs Victor to comment.)
>> >> >>>
>> >> >>> 4. Android: Realtime input seems to have problems. I saw the
>> >> >>> problem
>> >> >>> here on my Moto G4 and Jacques reported it on Pixel. I think both
>> >> >>> are
>> >> >>> 64-bit CPUs, which may be a factor.  (I'm looking into this.)
>> >> >>>
>> >> >>> 1 and 4 should hopefully get done today.  I think we should look at
>> >> >>> Sunday or Monday now to get these resolved and to start the branch.
>> >> >>>
>> >> >>> Please reply here if there are any other issues found.
>> >> >>>
>> >> >>> Thanks,
>> >> >>> steven
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>

I think that I had proposed multiples times that we only use the last
official, pre-built, stable version released by CsoundQt, so obviously
I am find with that.  I was, and am still, critical of CsoundQt being
built for the Csound installer by AppVeyor. It was these kinds of
problems (having to test multiple CsoundQt builds against Csound...)
that I wanted to avoid.

Anyways, since Michael designed and put that part of the installer
together, I think it's on him now to address what happens here for
CsoundQt.

One other note: With a clean install, I am not getting the hanging in
CsoundQt as I did before with vst4cs being present. Perhaps as Tarmo
mentioned it has to do with some interference with another older
opcode lib or something like that; regardless, I think there is still
some kind of problem with vst4cs if it could possibly cause some kind
of hang/crash.

And just so we don't lose track, #7 should be Csound installer
installing into "c:\Program Files\csound-windows-x64" by default being
a problem.

On Fri, Dec 8, 2017 at 5:57 PM, Tarmo Johannes  wrote:
> Hi,
>
> #2 (CsoundQt virtual midi)
> I was not able to get CsoundQt running built against installed Csoun 6.10.
> So I could not debug. Can it be that the linsndfile-1.lib in my computer
> (that I have not updated fro some time) conflicts with the one in appveyor
> build.
>
> But the reason might be simple: from Configure->MIDI input interface I see
> "No RtMidi support" thus CsoundQt was just not built with RtMidi (most
> likely the necessary sources were not pulled and built by AppVeyor). Can it
> be?
>
>
> In CsoundQt 0.9.5 from the release it Works fine.
>
> If this can be a solution, we can think of leaving CsoundQt out of Appveyor
> installer and provide separaate installer for CsoundQt. I can think of
> preparing one. Better of course is that appveyor does the job, so everything
> comes from one place and has thus less possible conflicts.
>
> What do you think?
>
> greetings,
> tarmo
>
>
>
> 2017-12-09 0:31 GMT+02:00 Tarmo Johannes :
>>
>> Hello,
>>
>> Another strange thing I noticed -  the bin folder is missing
>> libsndfile-1.dll
>> Is it actually necessary? i guess when Csound is compiled against the MSVC
>> .lib library of sndfile, it might  not be needed.
>>
>> i noticed the probelm when I tried to start CsoundQt 0.9.5 from  zip file
>> by CsoundQt release. It  was built against Csound 6.09 and via some
>> dpendencies requires libsndfile.dll  When I copied the file from Csound 6.09
>> installation to folder of CsoundQt (mine), then it started fine.
>>
>> This problem happens only when user erases or removes the previous
>> installation, otherwise libsndfile-1.dll just stays there.  Thus it is not
>> really a bug, just good to know.
>>
>> t
>>
>>
>>
>>
>>
>> 2017-12-09 0:07 GMT+02:00 Steven Yi :
>>>
>>> Hi Tarmo:
>>>
>>> For missing DLL, does it show a kind of message or something?  And is
>>> this for CsoundQt only, or happen when running commandline csound?  I
>>> only have Windows 10 here so I am not sure what I can do here to test.
>>>
>>> On my system, when I went to use the installer it installed into
>>> Csound_x64.  I don't know if that's because I had a previous install
>>> already.  Perhaps Michael would know about this as it looks like
>>> something related to artifact name changing he discussed here.
>>>
>>> Thanks,
>>> steven
>>>
>>> On Fri, Dec 8, 2017 at 4:41 PM, Tarmo Johannes 
>>> wrote:
>>> > Hi,
>>> >
>>> >
>>> > about #1:
>>> >
>>> > I tried to install this version from AppVeyor on a virtual machine
>>> > running
>>> > Windows 8.1 but could not get CsoundQt running there - first it missed
>>> > some
>>> > dll files: (maybe it is a problem of my installation but for any cas I
>>> > report here:
>>> > api-ms-win-crt-heap-l1-1-0.dll
>>> > api-ms-win-crt-string-l1-1-0.dll
>>> > api-ms-win-crt-runtime-l1-1-0.dll
>>> > api-ms-win-crt-math-l1-1-0.dll
>>> >
>>> > Unfortunatley it did not start wiht message "This program is not able
>>> > to
>>> > start correctly". Most likely it the virtual machine, don't take it too
>>> > seriously. I will try to test in on a real Windows 10 later.
>>> >
>>> > I noticed that the installation path of Csound has changed - before it
>>> > was
>>> > Csounx64, now csound-windows-x64. Is it meant like this? That's why the
>>> > manual was not found. It is possible to set the manual's path in
>>> > CsoundQt
>>> > options but if the installation path stays like that, I would do
>>> > something
>>> > in CsoundQt code to look for that as well.
>>> >
>>> > tarmo
>>> >
>>> >
>>> > 2017-12-08 20:24 GMT+02:00 Steven Yi :
>>> >>
>>> >> Regarding #1 (Windows Installer, CsoundQt): CsoundQt is building and
>>> >> is included in the installer.  I can run it and it shows Csound output
>>> >> when running an example. DrunkWalk.csd from Iain's collection runs
>>> >> fine in realtime.  The installer tested was:
>>> >>
>>> >> https://ci.appveyor.com/project/csound/csound/build/6.10.968/artifacts
>>> >>
>>> >> I think #1 is then finished as CsoundQt is now in the installer.
>>> >> (There are a couple of other new issues however, see below.)
>>> >>
>>> >> Regarding #2: I found that CsoundQt on Windows hung whenever rendering
>>> >> was stopped.  Deleting vst4cs.dll from the opcode dir fixed that. I
>>> >> suspect that it is the same issue reported by Menno and Rory, and this
>>> >> should make the problem with vst4cs easy to test.
>>> >>
>>> >>
>>> >> New issues:
>>> >>
>>> >> #5 - CsoundQt: VirtualKeyboard doesn't seem to work. This has to do
>>> >> with the one built by AppVeyor.  If I use the 0.9.5 version released
>>> >> by Tarmo, VirtualKeyboard works fine.  Since this has to do with
>>> >> CsoundQt, I'll leave it to Michael.
>>> >>
>>> >> #6 - I noticed that the HTML manual does not appear in CsoundQt's
>>> >> opcode help.  This was reported earlier when users tested an earlier
>>> >> version of the installer.  Since this is related to CsoundQt, I will
>>> >> leave it Michael to solve.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On Fri, Dec 8, 2017 at 12:31 PM, Michael Gogins
>>> >>  wrote:
>>> >> > I will look at the vst4cs issue this evening or tomorrow.
>>> >> >
>>> >> > Best, Mike
>>> >> >
>>> >> > On Dec 8, 2017 11:58 AM, "Rory Walsh"  wrote:
>>> >> >>
>>> >> >> I too was having issues with Cabbage crashing on exit due to the
>>> >> >> present
>>> >> >> of vst4cs in the opcodes dir. I will check again tonight and report
>>> >> >> back.
>>> >> >>
>>> >> >> On 8 December 2017 at 16:48, Steven Yi  wrote:
>>> >> >>>
>>> >> >>> Hi All,
>>> >> >>>
>>> >> >>> We had discussed getting the release branch started today but I
>>> >> >>> think
>>> >> >>> there's a few open loops to close:
>>> >> >>>
>>> >> >>> 1. Windows: Static-linking for libsndfile: this is done but
>>> >> >>> there's
>>> >> >>> one issue left with CsoundQt missing from the installer.  A fix is
>>> >> >>> in
>>> >> >>> and it's being built on AppVeyor now.  Testing of the previous
>>> >> >>> Csound
>>> >> >>> installer though passed my own light testing, but it would be good
>>> >> >>> to
>>> >> >>> get last minute checks by other users and developers using the
>>> >> >>> API.
>>> >> >>> (I'm looking into this.)
>>> >> >>>
>>> >> >>> 2. vst4cs: this is reported to cause a crash with Blue just by its
>>> >> >>> presence in OPCODEDIR.  (Reported by Menno on Linux).  I suspect
>>> >> >>> this
>>> >> >>> may also cause crashes for other Csound API-based programs.
>>> >> >>> (Awaiting
>>> >> >>> Michael to fix.)
>>> >> >>>
>>> >> >>> 3. Realtime branch: This is work for the --realtime, particularly
>>> >> >>> being driven by support for Bela at the moment, happening in the
>>> >> >>> feature/realtime branch.  I think it's gone back and forth whether
>>> >> >>> this is will go into 6.10 or not.  (Needs Victor to comment.)
>>> >> >>>
>>> >> >>> 4. Android: Realtime input seems to have problems. I saw the
>>> >> >>> problem
>>> >> >>> here on my Moto G4 and Jacques reported it on Pixel. I think both
>>> >> >>> are
>>> >> >>> 64-bit CPUs, which may be a factor.  (I'm looking into this.)
>>> >> >>>
>>> >> >>> 1 and 4 should hopefully get done today.  I think we should look
>>> >> >>> at
>>> >> >>> Sunday or Monday now to get these resolved and to start the
>>> >> >>> branch.
>>> >> >>>
>>> >> >>> Please reply here if there are any other issues found.
>>> >> >>>
>>> >> >>> Thanks,
>>> >> >>> steven
>>> >> >>
>>> >> >>
>>> >> >
>>> >
>>> >
>>
>>

I haven't had a chance yet, will try today or tomorrow.

Best,
Mike

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


On Mon, Dec 11, 2017 at 1:30 PM, Rory Walsh  wrote:
> Hi Mike, you mentioned you would look into the vst4cs issue on Sunday, did
> you make any head way?
>
> On 9 December 2017 at 11:58, Rory Walsh  wrote:
>>
>> Sorry to throw a spanner in the works here but that vst4cs issue is still
>> present. I didn't notice it before because I didn't try recompiling any
>> instruments in Cabbage. CsoundQT still seem to run fine however.
>>
>> On 9 December 2017 at 09:35, Rory Walsh  wrote:
>>>
>>> For what it's worth, I'm not seeing any install to csound-windows-x64, so
>>> I think we can thankfully mark that as a none issue. I'm also not seeing any
>>> crashes on exit with Cabbage, either in standalone mode or when testing
>>> plugins.
>>>
>>> On 8 December 2017 at 23:37, Steven Yi  wrote:
>>>>
>>>> I think that I had proposed multiples times that we only use the last
>>>> official, pre-built, stable version released by CsoundQt, so obviously
>>>> I am find with that.  I was, and am still, critical of CsoundQt being
>>>> built for the Csound installer by AppVeyor. It was these kinds of
>>>> problems (having to test multiple CsoundQt builds against Csound...)
>>>> that I wanted to avoid.
>>>>
>>>> Anyways, since Michael designed and put that part of the installer
>>>> together, I think it's on him now to address what happens here for
>>>> CsoundQt.
>>>>
>>>> One other note: With a clean install, I am not getting the hanging in
>>>> CsoundQt as I did before with vst4cs being present. Perhaps as Tarmo
>>>> mentioned it has to do with some interference with another older
>>>> opcode lib or something like that; regardless, I think there is still
>>>> some kind of problem with vst4cs if it could possibly cause some kind
>>>> of hang/crash.
>>>>
>>>> And just so we don't lose track, #7 should be Csound installer
>>>> installing into "c:\Program Files\csound-windows-x64" by default being
>>>> a problem.
>>>>
>>>> On Fri, Dec 8, 2017 at 5:57 PM, Tarmo Johannes 
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > #2 (CsoundQt virtual midi)
>>>> > I was not able to get CsoundQt running built against installed Csoun
>>>> > 6.10.
>>>> > So I could not debug. Can it be that the linsndfile-1.lib in my
>>>> > computer
>>>> > (that I have not updated fro some time) conflicts with the one in
>>>> > appveyor
>>>> > build.
>>>> >
>>>> > But the reason might be simple: from Configure->MIDI input interface I
>>>> > see
>>>> > "No RtMidi support" thus CsoundQt was just not built with RtMidi (most
>>>> > likely the necessary sources were not pulled and built by AppVeyor).
>>>> > Can it
>>>> > be?
>>>> >
>>>> >
>>>> > In CsoundQt 0.9.5 from the release it Works fine.
>>>> >
>>>> > If this can be a solution, we can think of leaving CsoundQt out of
>>>> > Appveyor
>>>> > installer and provide separaate installer for CsoundQt. I can think of
>>>> > preparing one. Better of course is that appveyor does the job, so
>>>> > everything
>>>> > comes from one place and has thus less possible conflicts.
>>>> >
>>>> > What do you think?
>>>> >
>>>> > greetings,
>>>> > tarmo
>>>> >
>>>> >
>>>> >
>>>> > 2017-12-09 0:31 GMT+02:00 Tarmo Johannes :
>>>> >>
>>>> >> Hello,
>>>> >>
>>>> >> Another strange thing I noticed -  the bin folder is missing
>>>> >> libsndfile-1.dll
>>>> >> Is it actually necessary? i guess when Csound is compiled against the
>>>> >> MSVC
>>>> >> .lib library of sndfile, it might  not be needed.
>>>> >>
>>>> >> i noticed the probelm when I tried to start CsoundQt 0.9.5 from  zip
>>>> >> file
>>>> >> by CsoundQt release. It  was built against Csound 6.09 and via some
>>>> >> dpendencies requires libsndfile.dll  When I copied the file from
>>>> >> Csound 6.09
>>>> >> installation to folder of CsoundQt (mine), then it started fine.
>>>> >>
>>>> >> This problem happens only when user erases or removes the previous
>>>> >> installation, otherwise libsndfile-1.dll just stays there.  Thus it
>>>> >> is not
>>>> >> really a bug, just good to know.
>>>> >>
>>>> >> t
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> 2017-12-09 0:07 GMT+02:00 Steven Yi :
>>>> >>>
>>>> >>> Hi Tarmo:
>>>> >>>
>>>> >>> For missing DLL, does it show a kind of message or something?  And
>>>> >>> is
>>>> >>> this for CsoundQt only, or happen when running commandline csound?
>>>> >>> I
>>>> >>> only have Windows 10 here so I am not sure what I can do here to
>>>> >>> test.
>>>> >>>
>>>> >>> On my system, when I went to use the installer it installed into
>>>> >>> Csound_x64.  I don't know if that's because I had a previous install
>>>> >>> already.  Perhaps Michael would know about this as it looks like
>>>> >>> something related to artifact name changing he discussed here.
>>>> >>>
>>>> >>> Thanks,
>>>> >>> steven
>>>> >>>
>>>> >>> On Fri, Dec 8, 2017 at 4:41 PM, Tarmo Johannes 
>>>> >>> wrote:
>>>> >>> > Hi,
>>>> >>> >
>>>> >>> >
>>>> >>> > about #1:
>>>> >>> >
>>>> >>> > I tried to install this version from AppVeyor on a virtual machine
>>>> >>> > running
>>>> >>> > Windows 8.1 but could not get CsoundQt running there - first it
>>>> >>> > missed
>>>> >>> > some
>>>> >>> > dll files: (maybe it is a problem of my installation but for any
>>>> >>> > cas I
>>>> >>> > report here:
>>>> >>> > api-ms-win-crt-heap-l1-1-0.dll
>>>> >>> > api-ms-win-crt-string-l1-1-0.dll
>>>> >>> > api-ms-win-crt-runtime-l1-1-0.dll
>>>> >>> > api-ms-win-crt-math-l1-1-0.dll
>>>> >>> >
>>>> >>> > Unfortunatley it did not start wiht message "This program is not
>>>> >>> > able
>>>> >>> > to
>>>> >>> > start correctly". Most likely it the virtual machine, don't take
>>>> >>> > it too
>>>> >>> > seriously. I will try to test in on a real Windows 10 later.
>>>> >>> >
>>>> >>> > I noticed that the installation path of Csound has changed -
>>>> >>> > before it
>>>> >>> > was
>>>> >>> > Csounx64, now csound-windows-x64. Is it meant like this? That's
>>>> >>> > why the
>>>> >>> > manual was not found. It is possible to set the manual's path in
>>>> >>> > CsoundQt
>>>> >>> > options but if the installation path stays like that, I would do
>>>> >>> > something
>>>> >>> > in CsoundQt code to look for that as well.
>>>> >>> >
>>>> >>> > tarmo
>>>> >>> >
>>>> >>> >
>>>> >>> > 2017-12-08 20:24 GMT+02:00 Steven Yi :
>>>> >>> >>
>>>> >>> >> Regarding #1 (Windows Installer, CsoundQt): CsoundQt is building
>>>> >>> >> and
>>>> >>> >> is included in the installer.  I can run it and it shows Csound
>>>> >>> >> output
>>>> >>> >> when running an example. DrunkWalk.csd from Iain's collection
>>>> >>> >> runs
>>>> >>> >> fine in realtime.  The installer tested was:
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> https://ci.appveyor.com/project/csound/csound/build/6.10.968/artifacts
>>>> >>> >>
>>>> >>> >> I think #1 is then finished as CsoundQt is now in the installer.
>>>> >>> >> (There are a couple of other new issues however, see below.)
>>>> >>> >>
>>>> >>> >> Regarding #2: I found that CsoundQt on Windows hung whenever
>>>> >>> >> rendering
>>>> >>> >> was stopped.  Deleting vst4cs.dll from the opcode dir fixed that.
>>>> >>> >> I
>>>> >>> >> suspect that it is the same issue reported by Menno and Rory, and
>>>> >>> >> this
>>>> >>> >> should make the problem with vst4cs easy to test.
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> New issues:
>>>> >>> >>
>>>> >>> >> #5 - CsoundQt: VirtualKeyboard doesn't seem to work. This has to
>>>> >>> >> do
>>>> >>> >> with the one built by AppVeyor.  If I use the 0.9.5 version
>>>> >>> >> released
>>>> >>> >> by Tarmo, VirtualKeyboard works fine.  Since this has to do with
>>>> >>> >> CsoundQt, I'll leave it to Michael.
>>>> >>> >>
>>>> >>> >> #6 - I noticed that the HTML manual does not appear in CsoundQt's
>>>> >>> >> opcode help.  This was reported earlier when users tested an
>>>> >>> >> earlier
>>>> >>> >> version of the installer.  Since this is related to CsoundQt, I
>>>> >>> >> will
>>>> >>> >> leave it Michael to solve.
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> On Fri, Dec 8, 2017 at 12:31 PM, Michael Gogins
>>>> >>> >>  wrote:
>>>> >>> >> > I will look at the vst4cs issue this evening or tomorrow.
>>>> >>> >> >
>>>> >>> >> > Best, Mike
>>>> >>> >> >
>>>> >>> >> > On Dec 8, 2017 11:58 AM, "Rory Walsh"  wrote:
>>>> >>> >> >>
>>>> >>> >> >> I too was having issues with Cabbage crashing on exit due to
>>>> >>> >> >> the
>>>> >>> >> >> present
>>>> >>> >> >> of vst4cs in the opcodes dir. I will check again tonight and
>>>> >>> >> >> report
>>>> >>> >> >> back.
>>>> >>> >> >>
>>>> >>> >> >> On 8 December 2017 at 16:48, Steven Yi 
>>>> >>> >> >> wrote:
>>>> >>> >> >>>
>>>> >>> >> >>> Hi All,
>>>> >>> >> >>>
>>>> >>> >> >>> We had discussed getting the release branch started today but
>>>> >>> >> >>> I
>>>> >>> >> >>> think
>>>> >>> >> >>> there's a few open loops to close:
>>>> >>> >> >>>
>>>> >>> >> >>> 1. Windows: Static-linking for libsndfile: this is done but
>>>> >>> >> >>> there's
>>>> >>> >> >>> one issue left with CsoundQt missing from the installer.  A
>>>> >>> >> >>> fix is
>>>> >>> >> >>> in
>>>> >>> >> >>> and it's being built on AppVeyor now.  Testing of the
>>>> >>> >> >>> previous
>>>> >>> >> >>> Csound
>>>> >>> >> >>> installer though passed my own light testing, but it would be
>>>> >>> >> >>> good
>>>> >>> >> >>> to
>>>> >>> >> >>> get last minute checks by other users and developers using
>>>> >>> >> >>> the
>>>> >>> >> >>> API.
>>>> >>> >> >>> (I'm looking into this.)
>>>> >>> >> >>>
>>>> >>> >> >>> 2. vst4cs: this is reported to cause a crash with Blue just
>>>> >>> >> >>> by its
>>>> >>> >> >>> presence in OPCODEDIR.  (Reported by Menno on Linux).  I
>>>> >>> >> >>> suspect
>>>> >>> >> >>> this
>>>> >>> >> >>> may also cause crashes for other Csound API-based programs.
>>>> >>> >> >>> (Awaiting
>>>> >>> >> >>> Michael to fix.)
>>>> >>> >> >>>
>>>> >>> >> >>> 3. Realtime branch: This is work for the --realtime,
>>>> >>> >> >>> particularly
>>>> >>> >> >>> being driven by support for Bela at the moment, happening in
>>>> >>> >> >>> the
>>>> >>> >> >>> feature/realtime branch.  I think it's gone back and forth
>>>> >>> >> >>> whether
>>>> >>> >> >>> this is will go into 6.10 or not.  (Needs Victor to comment.)
>>>> >>> >> >>>
>>>> >>> >> >>> 4. Android: Realtime input seems to have problems. I saw the
>>>> >>> >> >>> problem
>>>> >>> >> >>> here on my Moto G4 and Jacques reported it on Pixel. I think
>>>> >>> >> >>> both
>>>> >>> >> >>> are
>>>> >>> >> >>> 64-bit CPUs, which may be a factor.  (I'm looking into this.)
>>>> >>> >> >>>
>>>> >>> >> >>> 1 and 4 should hopefully get done today.  I think we should
>>>> >>> >> >>> look
>>>> >>> >> >>> at
>>>> >>> >> >>> Sunday or Monday now to get these resolved and to start the
>>>> >>> >> >>> branch.
>>>> >>> >> >>>
>>>> >>> >> >>> Please reply here if there are any other issues found.
>>>> >>> >> >>>
>>>> >>> >> >>> Thanks,
>>>> >>> >> >>> steven
>>>> >>> >> >>
>>>> >>> >> >>
>>>> >>> >> >
>>>> >>> >
>>>> >>> >
>>>> >>
>>>> >>
>>>> >
>>>
>>>
>>

Here is the current status of crashes with the vst4cs opcodes on
Linux. I did not test on Windows.

TL;DR:

-- No problems with CsoundQt.
-- No problems with blue.
-- Problems with Cabbage but not (as far as I can tell) because of the
vst4cs opcodes.

The gory details follow.

This is on:

Linux Sun-Yukong 4.4.0-103-generic #126-Ubuntu SMP Mon Dec 4 16:23:28
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Built with:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.5'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-5 --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)

Csound develop branch commit 16eac02760816f1b665f163b5d6a1b8466487350

I installed the VST2 SDK from:

https://download.steinberg.net/sdk_downloads/vstsdk368_08_11_2017_build_121.zip

I built Csound with:

#!/bin/sh
clear
cd ~/csound/cs6make
rm CMakeCache.txt
cmake ../csound -DSCORE_PARSER:BOOL=Yes
-DABLETON_LINK_HOME:PATH=/home/mkg/link
-DBUILD_ABLETON_LINK_OPCODES:BOOL=Yes -DBUILD_STATIC_LIBRARY:Bool=Yes
-DBUILD_TESTS:BOOL=Yes -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DBUILD_HDF5_OPCODES:BOOL=Yes
-DVSTSDK2X_INCLUDE_DIR:PATH=/home/mkg/VST_SDK/VST2_SDK
-DBUILD_CSOUND_VST=1 -DBUILD_VST4CS_OPCODES=1
-DLLVM_DIR=/usr/local/lib/cmake/llvm -DCMAKE_MODULE_LINKER_FLAGS="-L
/usr/local/lib" -DFAUST_LIBRARY=/usr/local/lib/libfaust.a
-DBUILD_FAUST_OPCODES:BOOL=No
make VERBOSE=1 -j6 $1
if [ "$1" = "clean" ]
then
    exit
fi

I installed Csound with:

sudo make install

I built CsoundQt master branch commit
9592159dedca3723693f390c8d5c9cc01eb415b3 using qtcreator, and ran
CsoundQt from qtcreator.

I ran the following test csd:



; Credits: Adapted by Michael Gogins
; from code by David Horowitz and Lian Cheung.
; The "--displays" option is required in order for
; the Pianoteq GUI to dispatch events and display properly.
-m3 --displays -odac


sr     = 44100
ksmps  = 20
nchnls = 2 ; Changed for WebAssembly output from: = 2
                ; Load the Pianoteq into memory.
gipianoteq      vstinit         "/home/mkg/Pianoteq\ 6/amd64/Pianoteq\ 6.so", 0

                ; Print information about the Pianoteq, such as
parameter names and numbers.
                vstinfo         gipianoteq

                ; Open the Pianoteq's GUI.
                ;vstedit         gipianoteq

                ; Send notes from the score to the Pianoteq.
                instr 1
                ; MIDI channels are numbered starting at 0.
                ; p3 always contains the duration of the note.
                ; p4 contains the MIDI key number (pitch),
                ; p5 contains the MIDI velocity number (loudness),
imidichannel    init            0
                vstnote         gipianoteq, imidichannel, p4, p5, p3
                endin

                ; Send parameter changes to the Pianoteq.
                instr 2
                ; p4 is the parameter number.
                ; p5 is the parameter value.
                vstparamset     gipianoteq, p4, p5
                endin

                ; Send audio from the Pianoteq to the output.
                instr 3
ablankinput     init            0
aleft, aright   vstaudio        gipianoteq, ablankinput, ablankinput
                outs            aleft, aright
                endin



; Turn on the instrument that receives audio from the Pianoteq indefinitely.
i 3 0 -1
; Send parameter changes to Pianoteq before sending any notes.
; NOTE: All parameters must be between 0.0 and 1.0.
; Length of piano strings:
i 2 0 1 33 0.5
; Hammer noise:
i 2 0 1 25 0.1
; Send a C major 7th arpeggio to the Pianoteq.
i 1 1 10 60 76
i 1 2 10 64 73
i 1 3 10 67 70
i 1 4 10 71 67
; End the performance, leaving some time
; for the Pianoteq to finish sending out its audio,
; or for the user to play with the Pianoteq virtual keyboard.
e 20



This ran fine from the Linux terminal, from CsoundQt, from CsoundQt in
terminal. It re-ran fine. It ran and was stopped with Ctrl-C fine.

I installed blue 2.7.2 from:

https://github.com/kunstmusik/blue/releases/download/2.7.2/blue_2.7.2.zip

I ran /home/blue/bin/blue.

I imported the CSD above into the blue global orc and sco.

I rendered. No problem.

I exited blue. No problem.

I installed Cabbage sources from:

https://github.com/rorywalsh/cabbage_v1_old/archive/v1.0.0.zip

I updated dependencies and built according to instructions.

NOTE: The Juce VST plugin adapter did not find the VST SDK sources in
spite of my having followed instructions. Perhaps the instructions
should be clarified.

Any way Cabbage and Cabbage Studio both built and both ran.

I could not get Cabbage to change the Instruments directory, or to
load an instrument. The Cabbage audio output worked with both Jack and
Alsa.

I was able to get the above CSD to play in Cabbage standalone by
pasting it into the startup instrument. I replaced "-odac" with "-h".

The sound was sometimes glitchy and distorted. I couldn't exit from
Cabbage. Then I got this backtrace in gdb:

*** Error in `/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage':
double free or corruption (!prev): 0x0000000006c30f00 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7ffff59c07e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7ffff59c937a]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7ffff59cd53c]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4b7ce3]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4b7e78]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x504a32]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x504a6e]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x505bcc]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x505bf9]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x50a524]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4d9b1b]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4db624]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4e053c]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x689310]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x63fddf]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x65e80d]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x69c69b]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x69d26a]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x65fa18]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x65fba6]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x69d5b4]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x69d8fb]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x69e513]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x5afa52]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x5af446]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x5af4d9]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x423ed7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ffff5969830]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x426609]

I tried again after removing vst4cs from the opcode dir. I had to
replace my Pianoteq csd with the example xanadu.csd to get any sound.
It was still impossible to quit or to set the examples dir.

On trying to quit I got this trace:

======EDITOR DECONSTRCUTOR=========
about to cleanup Csound
Csound cleaned up
[Thread 0x7fffda79e700 (LWP 29741) exited]
[Thread 0x7fffdaf9f700 (LWP 29740) exited]
[Thread 0x7fffdf9a8700 (LWP 29739) exited]
*** Error in `/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage':
corrupted size vs. prev_size: 0x0000000000f83ab0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7ffff59c07e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x80dfb)[0x7ffff59c9dfb]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7ffff59cd53c]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4b7ce3]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4b7e78]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x504a14]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x504a6e]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x505bcc]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x505bf9]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x50a524]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x505875]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x50597f]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4db03e]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4db239]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4e51a8]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x5adb08]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x423edf]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ffff5969830]
/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x426609]

Best,
Mike



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


On Mon, Dec 11, 2017 at 2:02 PM, Michael Gogins
 wrote:
> I haven't had a chance yet, will try today or tomorrow.
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Mon, Dec 11, 2017 at 1:30 PM, Rory Walsh  wrote:
>> Hi Mike, you mentioned you would look into the vst4cs issue on Sunday, did
>> you make any head way?
>>
>> On 9 December 2017 at 11:58, Rory Walsh  wrote:
>>>
>>> Sorry to throw a spanner in the works here but that vst4cs issue is still
>>> present. I didn't notice it before because I didn't try recompiling any
>>> instruments in Cabbage. CsoundQT still seem to run fine however.
>>>
>>> On 9 December 2017 at 09:35, Rory Walsh  wrote:
>>>>
>>>> For what it's worth, I'm not seeing any install to csound-windows-x64, so
>>>> I think we can thankfully mark that as a none issue. I'm also not seeing any
>>>> crashes on exit with Cabbage, either in standalone mode or when testing
>>>> plugins.
>>>>
>>>> On 8 December 2017 at 23:37, Steven Yi  wrote:
>>>>>
>>>>> I think that I had proposed multiples times that we only use the last
>>>>> official, pre-built, stable version released by CsoundQt, so obviously
>>>>> I am find with that.  I was, and am still, critical of CsoundQt being
>>>>> built for the Csound installer by AppVeyor. It was these kinds of
>>>>> problems (having to test multiple CsoundQt builds against Csound...)
>>>>> that I wanted to avoid.
>>>>>
>>>>> Anyways, since Michael designed and put that part of the installer
>>>>> together, I think it's on him now to address what happens here for
>>>>> CsoundQt.
>>>>>
>>>>> One other note: With a clean install, I am not getting the hanging in
>>>>> CsoundQt as I did before with vst4cs being present. Perhaps as Tarmo
>>>>> mentioned it has to do with some interference with another older
>>>>> opcode lib or something like that; regardless, I think there is still
>>>>> some kind of problem with vst4cs if it could possibly cause some kind
>>>>> of hang/crash.
>>>>>
>>>>> And just so we don't lose track, #7 should be Csound installer
>>>>> installing into "c:\Program Files\csound-windows-x64" by default being
>>>>> a problem.
>>>>>
>>>>> On Fri, Dec 8, 2017 at 5:57 PM, Tarmo Johannes 
>>>>> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > #2 (CsoundQt virtual midi)
>>>>> > I was not able to get CsoundQt running built against installed Csoun
>>>>> > 6.10.
>>>>> > So I could not debug. Can it be that the linsndfile-1.lib in my
>>>>> > computer
>>>>> > (that I have not updated fro some time) conflicts with the one in
>>>>> > appveyor
>>>>> > build.
>>>>> >
>>>>> > But the reason might be simple: from Configure->MIDI input interface I
>>>>> > see
>>>>> > "No RtMidi support" thus CsoundQt was just not built with RtMidi (most
>>>>> > likely the necessary sources were not pulled and built by AppVeyor).
>>>>> > Can it
>>>>> > be?
>>>>> >
>>>>> >
>>>>> > In CsoundQt 0.9.5 from the release it Works fine.
>>>>> >
>>>>> > If this can be a solution, we can think of leaving CsoundQt out of
>>>>> > Appveyor
>>>>> > installer and provide separaate installer for CsoundQt. I can think of
>>>>> > preparing one. Better of course is that appveyor does the job, so
>>>>> > everything
>>>>> > comes from one place and has thus less possible conflicts.
>>>>> >
>>>>> > What do you think?
>>>>> >
>>>>> > greetings,
>>>>> > tarmo
>>>>> >
>>>>> >
>>>>> >
>>>>> > 2017-12-09 0:31 GMT+02:00 Tarmo Johannes :
>>>>> >>
>>>>> >> Hello,
>>>>> >>
>>>>> >> Another strange thing I noticed -  the bin folder is missing
>>>>> >> libsndfile-1.dll
>>>>> >> Is it actually necessary? i guess when Csound is compiled against the
>>>>> >> MSVC
>>>>> >> .lib library of sndfile, it might  not be needed.
>>>>> >>
>>>>> >> i noticed the probelm when I tried to start CsoundQt 0.9.5 from  zip
>>>>> >> file
>>>>> >> by CsoundQt release. It  was built against Csound 6.09 and via some
>>>>> >> dpendencies requires libsndfile.dll  When I copied the file from
>>>>> >> Csound 6.09
>>>>> >> installation to folder of CsoundQt (mine), then it started fine.
>>>>> >>
>>>>> >> This problem happens only when user erases or removes the previous
>>>>> >> installation, otherwise libsndfile-1.dll just stays there.  Thus it
>>>>> >> is not
>>>>> >> really a bug, just good to know.
>>>>> >>
>>>>> >> t
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> 2017-12-09 0:07 GMT+02:00 Steven Yi :
>>>>> >>>
>>>>> >>> Hi Tarmo:
>>>>> >>>
>>>>> >>> For missing DLL, does it show a kind of message or something?  And
>>>>> >>> is
>>>>> >>> this for CsoundQt only, or happen when running commandline csound?
>>>>> >>> I
>>>>> >>> only have Windows 10 here so I am not sure what I can do here to
>>>>> >>> test.
>>>>> >>>
>>>>> >>> On my system, when I went to use the installer it installed into
>>>>> >>> Csound_x64.  I don't know if that's because I had a previous install
>>>>> >>> already.  Perhaps Michael would know about this as it looks like
>>>>> >>> something related to artifact name changing he discussed here.
>>>>> >>>
>>>>> >>> Thanks,
>>>>> >>> steven
>>>>> >>>
>>>>> >>> On Fri, Dec 8, 2017 at 4:41 PM, Tarmo Johannes 
>>>>> >>> wrote:
>>>>> >>> > Hi,
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > about #1:
>>>>> >>> >
>>>>> >>> > I tried to install this version from AppVeyor on a virtual machine
>>>>> >>> > running
>>>>> >>> > Windows 8.1 but could not get CsoundQt running there - first it
>>>>> >>> > missed
>>>>> >>> > some
>>>>> >>> > dll files: (maybe it is a problem of my installation but for any
>>>>> >>> > cas I
>>>>> >>> > report here:
>>>>> >>> > api-ms-win-crt-heap-l1-1-0.dll
>>>>> >>> > api-ms-win-crt-string-l1-1-0.dll
>>>>> >>> > api-ms-win-crt-runtime-l1-1-0.dll
>>>>> >>> > api-ms-win-crt-math-l1-1-0.dll
>>>>> >>> >
>>>>> >>> > Unfortunatley it did not start wiht message "This program is not
>>>>> >>> > able
>>>>> >>> > to
>>>>> >>> > start correctly". Most likely it the virtual machine, don't take
>>>>> >>> > it too
>>>>> >>> > seriously. I will try to test in on a real Windows 10 later.
>>>>> >>> >
>>>>> >>> > I noticed that the installation path of Csound has changed -
>>>>> >>> > before it
>>>>> >>> > was
>>>>> >>> > Csounx64, now csound-windows-x64. Is it meant like this? That's
>>>>> >>> > why the
>>>>> >>> > manual was not found. It is possible to set the manual's path in
>>>>> >>> > CsoundQt
>>>>> >>> > options but if the installation path stays like that, I would do
>>>>> >>> > something
>>>>> >>> > in CsoundQt code to look for that as well.
>>>>> >>> >
>>>>> >>> > tarmo
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > 2017-12-08 20:24 GMT+02:00 Steven Yi :
>>>>> >>> >>
>>>>> >>> >> Regarding #1 (Windows Installer, CsoundQt): CsoundQt is building
>>>>> >>> >> and
>>>>> >>> >> is included in the installer.  I can run it and it shows Csound
>>>>> >>> >> output
>>>>> >>> >> when running an example. DrunkWalk.csd from Iain's collection
>>>>> >>> >> runs
>>>>> >>> >> fine in realtime.  The installer tested was:
>>>>> >>> >>
>>>>> >>> >>
>>>>> >>> >> https://ci.appveyor.com/project/csound/csound/build/6.10.968/artifacts
>>>>> >>> >>
>>>>> >>> >> I think #1 is then finished as CsoundQt is now in the installer.
>>>>> >>> >> (There are a couple of other new issues however, see below.)
>>>>> >>> >>
>>>>> >>> >> Regarding #2: I found that CsoundQt on Windows hung whenever
>>>>> >>> >> rendering
>>>>> >>> >> was stopped.  Deleting vst4cs.dll from the opcode dir fixed that.
>>>>> >>> >> I
>>>>> >>> >> suspect that it is the same issue reported by Menno and Rory, and
>>>>> >>> >> this
>>>>> >>> >> should make the problem with vst4cs easy to test.
>>>>> >>> >>
>>>>> >>> >>
>>>>> >>> >> New issues:
>>>>> >>> >>
>>>>> >>> >> #5 - CsoundQt: VirtualKeyboard doesn't seem to work. This has to
>>>>> >>> >> do
>>>>> >>> >> with the one built by AppVeyor.  If I use the 0.9.5 version
>>>>> >>> >> released
>>>>> >>> >> by Tarmo, VirtualKeyboard works fine.  Since this has to do with
>>>>> >>> >> CsoundQt, I'll leave it to Michael.
>>>>> >>> >>
>>>>> >>> >> #6 - I noticed that the HTML manual does not appear in CsoundQt's
>>>>> >>> >> opcode help.  This was reported earlier when users tested an
>>>>> >>> >> earlier
>>>>> >>> >> version of the installer.  Since this is related to CsoundQt, I
>>>>> >>> >> will
>>>>> >>> >> leave it Michael to solve.
>>>>> >>> >>
>>>>> >>> >>
>>>>> >>> >>
>>>>> >>> >>
>>>>> >>> >> On Fri, Dec 8, 2017 at 12:31 PM, Michael Gogins
>>>>> >>> >>  wrote:
>>>>> >>> >> > I will look at the vst4cs issue this evening or tomorrow.
>>>>> >>> >> >
>>>>> >>> >> > Best, Mike
>>>>> >>> >> >
>>>>> >>> >> > On Dec 8, 2017 11:58 AM, "Rory Walsh"  wrote:
>>>>> >>> >> >>
>>>>> >>> >> >> I too was having issues with Cabbage crashing on exit due to
>>>>> >>> >> >> the
>>>>> >>> >> >> present
>>>>> >>> >> >> of vst4cs in the opcodes dir. I will check again tonight and
>>>>> >>> >> >> report
>>>>> >>> >> >> back.
>>>>> >>> >> >>
>>>>> >>> >> >> On 8 December 2017 at 16:48, Steven Yi 
>>>>> >>> >> >> wrote:
>>>>> >>> >> >>>
>>>>> >>> >> >>> Hi All,
>>>>> >>> >> >>>
>>>>> >>> >> >>> We had discussed getting the release branch started today but
>>>>> >>> >> >>> I
>>>>> >>> >> >>> think
>>>>> >>> >> >>> there's a few open loops to close:
>>>>> >>> >> >>>
>>>>> >>> >> >>> 1. Windows: Static-linking for libsndfile: this is done but
>>>>> >>> >> >>> there's
>>>>> >>> >> >>> one issue left with CsoundQt missing from the installer.  A
>>>>> >>> >> >>> fix is
>>>>> >>> >> >>> in
>>>>> >>> >> >>> and it's being built on AppVeyor now.  Testing of the
>>>>> >>> >> >>> previous
>>>>> >>> >> >>> Csound
>>>>> >>> >> >>> installer though passed my own light testing, but it would be
>>>>> >>> >> >>> good
>>>>> >>> >> >>> to
>>>>> >>> >> >>> get last minute checks by other users and developers using
>>>>> >>> >> >>> the
>>>>> >>> >> >>> API.
>>>>> >>> >> >>> (I'm looking into this.)
>>>>> >>> >> >>>
>>>>> >>> >> >>> 2. vst4cs: this is reported to cause a crash with Blue just
>>>>> >>> >> >>> by its
>>>>> >>> >> >>> presence in OPCODEDIR.  (Reported by Menno on Linux).  I
>>>>> >>> >> >>> suspect
>>>>> >>> >> >>> this
>>>>> >>> >> >>> may also cause crashes for other Csound API-based programs.
>>>>> >>> >> >>> (Awaiting
>>>>> >>> >> >>> Michael to fix.)
>>>>> >>> >> >>>
>>>>> >>> >> >>> 3. Realtime branch: This is work for the --realtime,
>>>>> >>> >> >>> particularly
>>>>> >>> >> >>> being driven by support for Bela at the moment, happening in
>>>>> >>> >> >>> the
>>>>> >>> >> >>> feature/realtime branch.  I think it's gone back and forth
>>>>> >>> >> >>> whether
>>>>> >>> >> >>> this is will go into 6.10 or not.  (Needs Victor to comment.)
>>>>> >>> >> >>>
>>>>> >>> >> >>> 4. Android: Realtime input seems to have problems. I saw the
>>>>> >>> >> >>> problem
>>>>> >>> >> >>> here on my Moto G4 and Jacques reported it on Pixel. I think
>>>>> >>> >> >>> both
>>>>> >>> >> >>> are
>>>>> >>> >> >>> 64-bit CPUs, which may be a factor.  (I'm looking into this.)
>>>>> >>> >> >>>
>>>>> >>> >> >>> 1 and 4 should hopefully get done today.  I think we should
>>>>> >>> >> >>> look
>>>>> >>> >> >>> at
>>>>> >>> >> >>> Sunday or Monday now to get these resolved and to start the
>>>>> >>> >> >>> branch.
>>>>> >>> >> >>>
>>>>> >>> >> >>> Please reply here if there are any other issues found.
>>>>> >>> >> >>>
>>>>> >>> >> >>> Thanks,
>>>>> >>> >> >>> steven
>>>>> >>> >> >>
>>>>> >>> >> >>
>>>>> >>> >> >
>>>>> >>> >
>>>>> >>> >
>>>>> >>
>>>>> >>
>>>>> >
>>>>
>>>>
>>>

I took a quick look. My guess is your testing didn't do the same
things as what we're all using/testing.  The code has a static
vectors.  Menno's report has:

# C  [libvst4cs.so+0x14fc8]  std::vector >::size() const+0xa

as the crash site.

If I read it correctly, you should get a crash every time you create
two Csound instances, load modules, then reset or delete the two
Csound instances, one after the other.  This should trigger something
like this:

csoundLoadModules()    // instance a
csoundLoadModules()    // instance b
csoundDestroyModules() // instance a
csoundDestroyModules() // instance b, should crash here because
vst4cs's csoudnModuleDestroy does not check if vstPlugins is null

Because the vectors are static, it should be possible to crash Csound
in multiple other ways if actually using vst4cs opcode instances.
(For example, one instance of csound is running, another is reset
triggering destroy, statics are cleared, but first instance is still
running...) The above should crash for the situation where one does
not use any vst4cs opcodes and just loads/unloads the module.

This was probably triggered here in CsoundQt as I had multiple
projects/tabs open. I probably started one rendering, switched to
another tab, then started another project rendering.  For Blue, this
trigger probably happened when delete() was called on the Csound
object, which happens in the SWIG-generated destructor (which in turn
is indeterminately called at some point by the JVM's object finalizer
thread).  I am not sure about Cabbage, but I think Cabbage 2 regularly
will have multiple Csound instances created and destroyed while
running. (Rory could comment.)


Assuming the above to be the root cause, the following shows other
modules that should be reviewed (ran from the Opcodes folder):

$ grep csoundModuleDestroy * -n -r
ableton_link_opcodes.cpp:889:  PUBLIC int csoundModuleDestroy(CSOUND *csound)
ampmidid.cpp:193:  PUBLIC int csoundModuleDestroy(CSOUND *csound)
chua/ChuaOscillator.cpp:645:  PUBLIC int csoundModuleDestroy(CSOUND *csound)
doppler.cpp:324:  PUBLIC int csoundModuleDestroy(CSOUND *csound)
fluidOpcodes/fluidOpcodes.cpp:787:PUBLIC int csoundModuleDestroy(CSOUND *csound)
fluidOpcodes/fluidOpcodes.cpp:789:    //printf("csoundModuleDestroy:
%p \n", csound);
ftsamplebank.cpp:415:  PUBLIC int csoundModuleDestroy(CSOUND *csound)
gab/newgabopc.c:689:PUBLIC  int     csoundModuleDestroy(CSOUND *csound)
jacko.cpp:1618:  PUBLIC int csoundModuleDestroy(CSOUND *csound)
linear_algebra.cpp:6336:  PUBLIC int csoundModuleDestroy(CSOUND *csound)
LuaCsound.cpp:732:    PUBLIC int csoundModuleDestroy(CSOUND *csound)
mixer.cpp:386:    PUBLIC int csoundModuleDestroy_mixer(CSOUND *csound)
mixer.cpp:430:    PUBLIC int csoundModuleDestroy(CSOUND *csound)
mixer.cpp:432:        return csoundModuleDestroy_mixer(csound);
signalflowgraph.cpp:1766:    PUBLIC int csoundModuleDestroy(CSOUND *csound)
signalflowgraph.cpp:1769:            csound->Message(csound,
"signalflowgraph: csoundModuleDestroy(%p)\n", csound);
stk/stkOpcodes.cpp:781:  PUBLIC int csoundModuleDestroy(CSOUND *csound)
tl/fractalnoise.cpp:464:    PUBLIC int csoundModuleDestroy(CSOUND *csound)
vst4cs/src/vst4cs.cpp:624:    PUBLIC int csoundModuleDestroy(CSOUND *csound)

Some of these have empty csoundModuleDestroy functions.  Others have
static vector usage similar to vst4cs that could potentially crash
Csound for API users.


On Mon, Dec 11, 2017 at 8:43 PM, Michael Gogins
 wrote:
> Here is the current status of crashes with the vst4cs opcodes on
> Linux. I did not test on Windows.
>
> TL;DR:
>
> -- No problems with CsoundQt.
> -- No problems with blue.
> -- Problems with Cabbage but not (as far as I can tell) because of the
> vst4cs opcodes.
>
> The gory details follow.
>
> This is on:
>
> Linux Sun-Yukong 4.4.0-103-generic #126-Ubuntu SMP Mon Dec 4 16:23:28
> UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>
> Built with:
>
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 5.4.0-6ubuntu1~16.04.5'
> --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
> --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
> --prefix=/usr --program-suffix=-5 --enable-shared
> --enable-linker-build-id --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --libdir=/usr/lib
> --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-libstdcxx-time=yes
> --with-default-libstdcxx-abi=new --enable-gnu-unique-object
> --disable-vtable-verify --enable-libmpx --enable-plugin
> --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
> --enable-gtk-cairo
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre
> --enable-java-home
> --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
> --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
> --with-arch-directory=amd64
> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
> --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
> --with-multilib-list=m32,m64,mx32 --enable-multilib
> --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
>
> Csound develop branch commit 16eac02760816f1b665f163b5d6a1b8466487350
>
> I installed the VST2 SDK from:
>
> https://download.steinberg.net/sdk_downloads/vstsdk368_08_11_2017_build_121.zip
>
> I built Csound with:
>
> #!/bin/sh
> clear
> cd ~/csound/cs6make
> rm CMakeCache.txt
> cmake ../csound -DSCORE_PARSER:BOOL=Yes
> -DABLETON_LINK_HOME:PATH=/home/mkg/link
> -DBUILD_ABLETON_LINK_OPCODES:BOOL=Yes -DBUILD_STATIC_LIBRARY:Bool=Yes
> -DBUILD_TESTS:BOOL=Yes -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DBUILD_HDF5_OPCODES:BOOL=Yes
> -DVSTSDK2X_INCLUDE_DIR:PATH=/home/mkg/VST_SDK/VST2_SDK
> -DBUILD_CSOUND_VST=1 -DBUILD_VST4CS_OPCODES=1
> -DLLVM_DIR=/usr/local/lib/cmake/llvm -DCMAKE_MODULE_LINKER_FLAGS="-L
> /usr/local/lib" -DFAUST_LIBRARY=/usr/local/lib/libfaust.a
> -DBUILD_FAUST_OPCODES:BOOL=No
> make VERBOSE=1 -j6 $1
> if [ "$1" = "clean" ]
> then
>     exit
> fi
>
> I installed Csound with:
>
> sudo make install
>
> I built CsoundQt master branch commit
> 9592159dedca3723693f390c8d5c9cc01eb415b3 using qtcreator, and ran
> CsoundQt from qtcreator.
>
> I ran the following test csd:
>
> 
> 
> ; Credits: Adapted by Michael Gogins
> ; from code by David Horowitz and Lian Cheung.
> ; The "--displays" option is required in order for
> ; the Pianoteq GUI to dispatch events and display properly.
> -m3 --displays -odac
> 
> 
> sr     = 44100
> ksmps  = 20
> nchnls = 2 ; Changed for WebAssembly output from: = 2
>                 ; Load the Pianoteq into memory.
> gipianoteq      vstinit         "/home/mkg/Pianoteq\ 6/amd64/Pianoteq\ 6.so", 0
>
>                 ; Print information about the Pianoteq, such as
> parameter names and numbers.
>                 vstinfo         gipianoteq
>
>                 ; Open the Pianoteq's GUI.
>                 ;vstedit         gipianoteq
>
>                 ; Send notes from the score to the Pianoteq.
>                 instr 1
>                 ; MIDI channels are numbered starting at 0.
>                 ; p3 always contains the duration of the note.
>                 ; p4 contains the MIDI key number (pitch),
>                 ; p5 contains the MIDI velocity number (loudness),
> imidichannel    init            0
>                 vstnote         gipianoteq, imidichannel, p4, p5, p3
>                 endin
>
>                 ; Send parameter changes to the Pianoteq.
>                 instr 2
>                 ; p4 is the parameter number.
>                 ; p5 is the parameter value.
>                 vstparamset     gipianoteq, p4, p5
>                 endin
>
>                 ; Send audio from the Pianoteq to the output.
>                 instr 3
> ablankinput     init            0
> aleft, aright   vstaudio        gipianoteq, ablankinput, ablankinput
>                 outs            aleft, aright
>                 endin
>
> 
> 
> ; Turn on the instrument that receives audio from the Pianoteq indefinitely.
> i 3 0 -1
> ; Send parameter changes to Pianoteq before sending any notes.
> ; NOTE: All parameters must be between 0.0 and 1.0.
> ; Length of piano strings:
> i 2 0 1 33 0.5
> ; Hammer noise:
> i 2 0 1 25 0.1
> ; Send a C major 7th arpeggio to the Pianoteq.
> i 1 1 10 60 76
> i 1 2 10 64 73
> i 1 3 10 67 70
> i 1 4 10 71 67
> ; End the performance, leaving some time
> ; for the Pianoteq to finish sending out its audio,
> ; or for the user to play with the Pianoteq virtual keyboard.
> e 20
> 
> 
>
> This ran fine from the Linux terminal, from CsoundQt, from CsoundQt in
> terminal. It re-ran fine. It ran and was stopped with Ctrl-C fine.
>
> I installed blue 2.7.2 from:
>
> https://github.com/kunstmusik/blue/releases/download/2.7.2/blue_2.7.2.zip
>
> I ran /home/blue/bin/blue.
>
> I imported the CSD above into the blue global orc and sco.
>
> I rendered. No problem.
>
> I exited blue. No problem.
>
> I installed Cabbage sources from:
>
> https://github.com/rorywalsh/cabbage_v1_old/archive/v1.0.0.zip
>
> I updated dependencies and built according to instructions.
>
> NOTE: The Juce VST plugin adapter did not find the VST SDK sources in
> spite of my having followed instructions. Perhaps the instructions
> should be clarified.
>
> Any way Cabbage and Cabbage Studio both built and both ran.
>
> I could not get Cabbage to change the Instruments directory, or to
> load an instrument. The Cabbage audio output worked with both Jack and
> Alsa.
>
> I was able to get the above CSD to play in Cabbage standalone by
> pasting it into the startup instrument. I replaced "-odac" with "-h".
>
> The sound was sometimes glitchy and distorted. I couldn't exit from
> Cabbage. Then I got this backtrace in gdb:
>
> *** Error in `/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage':
> double free or corruption (!prev): 0x0000000006c30f00 ***
> ======= Backtrace: =========
> /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7ffff59c07e5]
> /lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7ffff59c937a]
> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7ffff59cd53c]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4b7ce3]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4b7e78]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x504a32]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x504a6e]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x505bcc]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x505bf9]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x50a524]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4d9b1b]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4db624]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4e053c]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x689310]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x63fddf]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x65e80d]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x69c69b]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x69d26a]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x65fa18]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x65fba6]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x69d5b4]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x69d8fb]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x69e513]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x5afa52]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x5af446]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x5af4d9]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x423ed7]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ffff5969830]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x426609]
>
> I tried again after removing vst4cs from the opcode dir. I had to
> replace my Pianoteq csd with the example xanadu.csd to get any sound.
> It was still impossible to quit or to set the examples dir.
>
> On trying to quit I got this trace:
>
> ======EDITOR DECONSTRCUTOR=========
> about to cleanup Csound
> Csound cleaned up
> [Thread 0x7fffda79e700 (LWP 29741) exited]
> [Thread 0x7fffdaf9f700 (LWP 29740) exited]
> [Thread 0x7fffdf9a8700 (LWP 29739) exited]
> *** Error in `/home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage':
> corrupted size vs. prev_size: 0x0000000000f83ab0 ***
> ======= Backtrace: =========
> /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7ffff59c07e5]
> /lib/x86_64-linux-gnu/libc.so.6(+0x80dfb)[0x7ffff59c9dfb]
> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7ffff59cd53c]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4b7ce3]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4b7e78]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x504a14]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x504a6e]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x505bcc]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x505bf9]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x50a524]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x505875]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x50597f]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4db03e]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4db239]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x4e51a8]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x5adb08]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x423edf]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7ffff5969830]
> /home/mkg/csound/cabbage_v1_old-1.0.0/Builds/Linux/build/Cabbage[0x426609]
>
> Best,
> Mike
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Mon, Dec 11, 2017 at 2:02 PM, Michael Gogins
>  wrote:
>> I haven't had a chance yet, will try today or tomorrow.
>>
>> Best,
>> Mike
>>
>> -----------------------------------------------------
>> Michael Gogins
>> Irreducible Productions
>> http://michaelgogins.tumblr.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> On Mon, Dec 11, 2017 at 1:30 PM, Rory Walsh  wrote:
>>> Hi Mike, you mentioned you would look into the vst4cs issue on Sunday, did
>>> you make any head way?
>>>
>>> On 9 December 2017 at 11:58, Rory Walsh  wrote:
>>>>
>>>> Sorry to throw a spanner in the works here but that vst4cs issue is still
>>>> present. I didn't notice it before because I didn't try recompiling any
>>>> instruments in Cabbage. CsoundQT still seem to run fine however.
>>>>
>>>> On 9 December 2017 at 09:35, Rory Walsh  wrote:
>>>>>
>>>>> For what it's worth, I'm not seeing any install to csound-windows-x64, so
>>>>> I think we can thankfully mark that as a none issue. I'm also not seeing any
>>>>> crashes on exit with Cabbage, either in standalone mode or when testing
>>>>> plugins.
>>>>>
>>>>> On 8 December 2017 at 23:37, Steven Yi  wrote:
>>>>>>
>>>>>> I think that I had proposed multiples times that we only use the last
>>>>>> official, pre-built, stable version released by CsoundQt, so obviously
>>>>>> I am find with that.  I was, and am still, critical of CsoundQt being
>>>>>> built for the Csound installer by AppVeyor. It was these kinds of
>>>>>> problems (having to test multiple CsoundQt builds against Csound...)
>>>>>> that I wanted to avoid.
>>>>>>
>>>>>> Anyways, since Michael designed and put that part of the installer
>>>>>> together, I think it's on him now to address what happens here for
>>>>>> CsoundQt.
>>>>>>
>>>>>> One other note: With a clean install, I am not getting the hanging in
>>>>>> CsoundQt as I did before with vst4cs being present. Perhaps as Tarmo
>>>>>> mentioned it has to do with some interference with another older
>>>>>> opcode lib or something like that; regardless, I think there is still
>>>>>> some kind of problem with vst4cs if it could possibly cause some kind
>>>>>> of hang/crash.
>>>>>>
>>>>>> And just so we don't lose track, #7 should be Csound installer
>>>>>> installing into "c:\Program Files\csound-windows-x64" by default being
>>>>>> a problem.
>>>>>>
>>>>>> On Fri, Dec 8, 2017 at 5:57 PM, Tarmo Johannes 
>>>>>> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > #2 (CsoundQt virtual midi)
>>>>>> > I was not able to get CsoundQt running built against installed Csoun
>>>>>> > 6.10.
>>>>>> > So I could not debug. Can it be that the linsndfile-1.lib in my
>>>>>> > computer
>>>>>> > (that I have not updated fro some time) conflicts with the one in
>>>>>> > appveyor
>>>>>> > build.
>>>>>> >
>>>>>> > But the reason might be simple: from Configure->MIDI input interface I
>>>>>> > see
>>>>>> > "No RtMidi support" thus CsoundQt was just not built with RtMidi (most
>>>>>> > likely the necessary sources were not pulled and built by AppVeyor).
>>>>>> > Can it
>>>>>> > be?
>>>>>> >
>>>>>> >
>>>>>> > In CsoundQt 0.9.5 from the release it Works fine.
>>>>>> >
>>>>>> > If this can be a solution, we can think of leaving CsoundQt out of
>>>>>> > Appveyor
>>>>>> > installer and provide separaate installer for CsoundQt. I can think of
>>>>>> > preparing one. Better of course is that appveyor does the job, so
>>>>>> > everything
>>>>>> > comes from one place and has thus less possible conflicts.
>>>>>> >
>>>>>> > What do you think?
>>>>>> >
>>>>>> > greetings,
>>>>>> > tarmo
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > 2017-12-09 0:31 GMT+02:00 Tarmo Johannes :
>>>>>> >>
>>>>>> >> Hello,
>>>>>> >>
>>>>>> >> Another strange thing I noticed -  the bin folder is missing
>>>>>> >> libsndfile-1.dll
>>>>>> >> Is it actually necessary? i guess when Csound is compiled against the
>>>>>> >> MSVC
>>>>>> >> .lib library of sndfile, it might  not be needed.
>>>>>> >>
>>>>>> >> i noticed the probelm when I tried to start CsoundQt 0.9.5 from  zip
>>>>>> >> file
>>>>>> >> by CsoundQt release. It  was built against Csound 6.09 and via some
>>>>>> >> dpendencies requires libsndfile.dll  When I copied the file from
>>>>>> >> Csound 6.09
>>>>>> >> installation to folder of CsoundQt (mine), then it started fine.
>>>>>> >>
>>>>>> >> This problem happens only when user erases or removes the previous
>>>>>> >> installation, otherwise libsndfile-1.dll just stays there.  Thus it
>>>>>> >> is not
>>>>>> >> really a bug, just good to know.
>>>>>> >>
>>>>>> >> t
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> 2017-12-09 0:07 GMT+02:00 Steven Yi :
>>>>>> >>>
>>>>>> >>> Hi Tarmo:
>>>>>> >>>
>>>>>> >>> For missing DLL, does it show a kind of message or something?  And
>>>>>> >>> is
>>>>>> >>> this for CsoundQt only, or happen when running commandline csound?
>>>>>> >>> I
>>>>>> >>> only have Windows 10 here so I am not sure what I can do here to
>>>>>> >>> test.
>>>>>> >>>
>>>>>> >>> On my system, when I went to use the installer it installed into
>>>>>> >>> Csound_x64.  I don't know if that's because I had a previous install
>>>>>> >>> already.  Perhaps Michael would know about this as it looks like
>>>>>> >>> something related to artifact name changing he discussed here.
>>>>>> >>>
>>>>>> >>> Thanks,
>>>>>> >>> steven
>>>>>> >>>
>>>>>> >>> On Fri, Dec 8, 2017 at 4:41 PM, Tarmo Johannes 
>>>>>> >>> wrote:
>>>>>> >>> > Hi,
>>>>>> >>> >
>>>>>> >>> >
>>>>>> >>> > about #1:
>>>>>> >>> >
>>>>>> >>> > I tried to install this version from AppVeyor on a virtual machine
>>>>>> >>> > running
>>>>>> >>> > Windows 8.1 but could not get CsoundQt running there - first it
>>>>>> >>> > missed
>>>>>> >>> > some
>>>>>> >>> > dll files: (maybe it is a problem of my installation but for any
>>>>>> >>> > cas I
>>>>>> >>> > report here:
>>>>>> >>> > api-ms-win-crt-heap-l1-1-0.dll
>>>>>> >>> > api-ms-win-crt-string-l1-1-0.dll
>>>>>> >>> > api-ms-win-crt-runtime-l1-1-0.dll
>>>>>> >>> > api-ms-win-crt-math-l1-1-0.dll
>>>>>> >>> >
>>>>>> >>> > Unfortunatley it did not start wiht message "This program is not
>>>>>> >>> > able
>>>>>> >>> > to
>>>>>> >>> > start correctly". Most likely it the virtual machine, don't take
>>>>>> >>> > it too
>>>>>> >>> > seriously. I will try to test in on a real Windows 10 later.
>>>>>> >>> >
>>>>>> >>> > I noticed that the installation path of Csound has changed -
>>>>>> >>> > before it
>>>>>> >>> > was
>>>>>> >>> > Csounx64, now csound-windows-x64. Is it meant like this? That's
>>>>>> >>> > why the
>>>>>> >>> > manual was not found. It is possible to set the manual's path in
>>>>>> >>> > CsoundQt
>>>>>> >>> > options but if the installation path stays like that, I would do
>>>>>> >>> > something
>>>>>> >>> > in CsoundQt code to look for that as well.
>>>>>> >>> >
>>>>>> >>> > tarmo
>>>>>> >>> >
>>>>>> >>> >
>>>>>> >>> > 2017-12-08 20:24 GMT+02:00 Steven Yi :
>>>>>> >>> >>
>>>>>> >>> >> Regarding #1 (Windows Installer, CsoundQt): CsoundQt is building
>>>>>> >>> >> and
>>>>>> >>> >> is included in the installer.  I can run it and it shows Csound
>>>>>> >>> >> output
>>>>>> >>> >> when running an example. DrunkWalk.csd from Iain's collection
>>>>>> >>> >> runs
>>>>>> >>> >> fine in realtime.  The installer tested was:
>>>>>> >>> >>
>>>>>> >>> >>
>>>>>> >>> >> https://ci.appveyor.com/project/csound/csound/build/6.10.968/artifacts
>>>>>> >>> >>
>>>>>> >>> >> I think #1 is then finished as CsoundQt is now in the installer.
>>>>>> >>> >> (There are a couple of other new issues however, see below.)
>>>>>> >>> >>
>>>>>> >>> >> Regarding #2: I found that CsoundQt on Windows hung whenever
>>>>>> >>> >> rendering
>>>>>> >>> >> was stopped.  Deleting vst4cs.dll from the opcode dir fixed that.
>>>>>> >>> >> I
>>>>>> >>> >> suspect that it is the same issue reported by Menno and Rory, and
>>>>>> >>> >> this
>>>>>> >>> >> should make the problem with vst4cs easy to test.
>>>>>> >>> >>
>>>>>> >>> >>
>>>>>> >>> >> New issues:
>>>>>> >>> >>
>>>>>> >>> >> #5 - CsoundQt: VirtualKeyboard doesn't seem to work. This has to
>>>>>> >>> >> do
>>>>>> >>> >> with the one built by AppVeyor.  If I use the 0.9.5 version
>>>>>> >>> >> released
>>>>>> >>> >> by Tarmo, VirtualKeyboard works fine.  Since this has to do with
>>>>>> >>> >> CsoundQt, I'll leave it to Michael.
>>>>>> >>> >>
>>>>>> >>> >> #6 - I noticed that the HTML manual does not appear in CsoundQt's
>>>>>> >>> >> opcode help.  This was reported earlier when users tested an
>>>>>> >>> >> earlier
>>>>>> >>> >> version of the installer.  Since this is related to CsoundQt, I
>>>>>> >>> >> will
>>>>>> >>> >> leave it Michael to solve.
>>>>>> >>> >>
>>>>>> >>> >>
>>>>>> >>> >>
>>>>>> >>> >>
>>>>>> >>> >> On Fri, Dec 8, 2017 at 12:31 PM, Michael Gogins
>>>>>> >>> >>  wrote:
>>>>>> >>> >> > I will look at the vst4cs issue this evening or tomorrow.
>>>>>> >>> >> >
>>>>>> >>> >> > Best, Mike
>>>>>> >>> >> >
>>>>>> >>> >> > On Dec 8, 2017 11:58 AM, "Rory Walsh"  wrote:
>>>>>> >>> >> >>
>>>>>> >>> >> >> I too was having issues with Cabbage crashing on exit due to
>>>>>> >>> >> >> the
>>>>>> >>> >> >> present
>>>>>> >>> >> >> of vst4cs in the opcodes dir. I will check again tonight and
>>>>>> >>> >> >> report
>>>>>> >>> >> >> back.
>>>>>> >>> >> >>
>>>>>> >>> >> >> On 8 December 2017 at 16:48, Steven Yi 
>>>>>> >>> >> >> wrote:
>>>>>> >>> >> >>>
>>>>>> >>> >> >>> Hi All,
>>>>>> >>> >> >>>
>>>>>> >>> >> >>> We had discussed getting the release branch started today but
>>>>>> >>> >> >>> I
>>>>>> >>> >> >>> think
>>>>>> >>> >> >>> there's a few open loops to close:
>>>>>> >>> >> >>>
>>>>>> >>> >> >>> 1. Windows: Static-linking for libsndfile: this is done but
>>>>>> >>> >> >>> there's
>>>>>> >>> >> >>> one issue left with CsoundQt missing from the installer.  A
>>>>>> >>> >> >>> fix is
>>>>>> >>> >> >>> in
>>>>>> >>> >> >>> and it's being built on AppVeyor now.  Testing of the
>>>>>> >>> >> >>> previous
>>>>>> >>> >> >>> Csound
>>>>>> >>> >> >>> installer though passed my own light testing, but it would be
>>>>>> >>> >> >>> good
>>>>>> >>> >> >>> to
>>>>>> >>> >> >>> get last minute checks by other users and developers using
>>>>>> >>> >> >>> the
>>>>>> >>> >> >>> API.
>>>>>> >>> >> >>> (I'm looking into this.)
>>>>>> >>> >> >>>
>>>>>> >>> >> >>> 2. vst4cs: this is reported to cause a crash with Blue just
>>>>>> >>> >> >>> by its
>>>>>> >>> >> >>> presence in OPCODEDIR.  (Reported by Menno on Linux).  I
>>>>>> >>> >> >>> suspect
>>>>>> >>> >> >>> this
>>>>>> >>> >> >>> may also cause crashes for other Csound API-based programs.
>>>>>> >>> >> >>> (Awaiting
>>>>>> >>> >> >>> Michael to fix.)
>>>>>> >>> >> >>>
>>>>>> >>> >> >>> 3. Realtime branch: This is work for the --realtime,
>>>>>> >>> >> >>> particularly
>>>>>> >>> >> >>> being driven by support for Bela at the moment, happening in
>>>>>> >>> >> >>> the
>>>>>> >>> >> >>> feature/realtime branch.  I think it's gone back and forth
>>>>>> >>> >> >>> whether
>>>>>> >>> >> >>> this is will go into 6.10 or not.  (Needs Victor to comment.)
>>>>>> >>> >> >>>
>>>>>> >>> >> >>> 4. Android: Realtime input seems to have problems. I saw the
>>>>>> >>> >> >>> problem
>>>>>> >>> >> >>> here on my Moto G4 and Jacques reported it on Pixel. I think
>>>>>> >>> >> >>> both
>>>>>> >>> >> >>> are
>>>>>> >>> >> >>> 64-bit CPUs, which may be a factor.  (I'm looking into this.)
>>>>>> >>> >> >>>
>>>>>> >>> >> >>> 1 and 4 should hopefully get done today.  I think we should
>>>>>> >>> >> >>> look
>>>>>> >>> >> >>> at
>>>>>> >>> >> >>> Sunday or Monday now to get these resolved and to start the
>>>>>> >>> >> >>> branch.
>>>>>> >>> >> >>>
>>>>>> >>> >> >>> Please reply here if there are any other issues found.
>>>>>> >>> >> >>>
>>>>>> >>> >> >>> Thanks,
>>>>>> >>> >> >>> steven
>>>>>> >>> >> >>
>>>>>> >>> >> >>
>>>>>> >>> >> >
>>>>>> >>> >
>>>>>> >>> >
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>
>>>>>
>>>>