Re: SuperColliderAU and AsioThread

There are some build instructions here for SuperColliderAU

https://github.com/g-roma/supercollider/tree/topic/supercolliderau-update/platform/mac/SuperColliderAU

This should generate the component. This is still "not released" so I would rather not move the discussion to sc-users yet.

best,

gerard


El 2 març 2018, a les 3:49, [email protected]<mailto:[email protected]> va escriure:

Thank you Gerard for the reply!

I can compile the supercollider version from your link.
Then to produce the AU.component I was using an old "SuperColliderAU.component". So, this may explain your point about wrong format.
I don't know how to produce a new one, does it need a different compilation process?

Should this be moved to the user list?

Best,
Alejandro



On 26 Feb 2018, at 15.39, [email protected]<mailto:[email protected]> wrote:

Hi Alejandro, thanks for trying it. Could you describe what you are doing and your OS version?
Also please make sure you try the latest version of this branch:
https://github.com/g-roma/supercollider/tree/topic/supercolliderau-update
(note it was updated a couple weeks ago)

This supports using the server inside an AU hosts. It also works for standalone plugins, but I have still not pushed the update for the AudioUnitBuilder quark. I have seen the errors you describe when auval is run in 32-bit mode, which is not supported. Try using auvaltool directly (I have seen some machine where auval calls auvaltool in 32bit).

I have plans for moving the project forward, but for the moment my priority is restoring functionality. So far it works for me on El Capitan and Sierra.

best,

gerard



2018-02-26 8:24 GMT+00:00 <[email protected]<mailto:[email protected]>>:
This a great effort Gerard!

Though, I haven't been able to compile any example I hope this will move forward.

I can produce the component file but the auval procedure gives an error:
ERROR: Cannot get Component's Name strings
ERROR: Error from retrieving Component Version: -50

It will be great to recover the function to create Audio Units. It makes easier to share the work done within sc and make it more interactive with other platforms.
There was also at some point a bit of enthusiasm on the release of the VST licensing that make some sparkling eyes but I am sure it will require bigger efforts before we will see some utility.

Not for comparison of course but I just run the Juce-Gen-Max example for producing VST and it did work (grrrr again)

Since I am not a developer and I am here more as a follower/supporter I tough I could through an Idea based on past experiences: "Fund raising"
I believe many sc-users will be happy to contribute for paying a developer to get us the chance to write again AU or VST from native supercollider language.

What do you think? Am I dreaming too much?

Best regards,

Alejandro




On 22 Dec 2017, at 19.06, [email protected]<mailto:[email protected]> wrote:

So this seems to fix it for starting new instances:

if (!gAsioThread.joinable()){
SC_Thread asioThread (&asioFunction);
gAsioThread = std::move(asioThread);
}

However the host will still crash when exiting after allocating more than one instance, so I'll keep beating it...

thanks

gerard


2017-12-22 17:30 GMT+01:00 <[email protected]<mailto:[email protected]>>:
> I think it would not work otherwise, I could try duplicating it but it would look ugly.

All right! Not very familiar with what you're doing so I just wanted to make sure.

On Fri, Dec 22, 2017 at 10:28 AM, <[email protected]<mailto:[email protected]>> wrote:
 Is it absolutely necessary for you to call World_New multiple times?
I think it would not work otherwise, I could try duplicating it but it would look ugly.

Perhaps we could alter this code to avoid constructing a new asio thread if one is currently running (i.e., `if (gAsioThread && gAsioThread.joinable())`). Maybe try that out and see if you run into any other issues.

yes I was looking for some form of that that the compiler will like ;)

best,

gerard





-Brian


On Fri, Dec 22, 2017 at 9:59 AM, <[email protected]<mailto:[email protected]>> wrote:


Having you tried determining the cause and location of the crash with a debugger?

I did not think I'd have to go that far  ;P
OK so I did now, the crash happens at
https://github.com/supercollider/supercollider/blob/develop/server/scsynth/SC_ComPort.cpp#L478
Not that I am very familiar with the move constructor, but my guess is that since gAsioThread already holds one thread it will terminate it before getting the new one.

best,

gerard


-Brian

On Fri, Dec 22, 2017 at 6:42 AM <[email protected]<mailto:[email protected]>> wrote:
Hi all, I am trying to bring SuperColliderAU back to life with current SC.
So far I have a version that works but only for one plugin instance. As long as I instantiate another plugin, the host crashes at World_New, where the asio thread is created  (SC_World.cpp:475).
Successive instantiations (as done e.g. by auval) work as long as the instance has been destroyed before starting a new one.

Since I'm not familiar with boost.asio, any pointers would be much appreciated. My main question is whether it is still safe to call World_New from multiple threads. In that case I wonder whether it could be anything in my own code that is creating the trouble...

Here's my fork, most of the relevant code is at SCProcess:
https://github.com/g-roma/supercollider/blob/develop/platform/mac/SuperColliderAU/Source/SCProcess.cpp

Any idea?

best,

gerard









University of Huddersfield inspiring tomorrow's professionals.
[http://marketing.hud.ac.uk/_HOSTED/EmailSig2014/EmailSigFooter.jpg]

This transmission is confidential and may be legally privileged. If you receive it in error, please notify us immediately by e-mail and remove it from your system. If the content of this e-mail does not relate to the business of the University of Huddersfield, then we do not endorse it and will accept no liability.