| Newsgroups |
gmane.comp.audio.supercollider.devel |
| Message-ID |
<[email protected]> |
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] 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 <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 <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 <https://github.com/g-roma/supercollider/blob/develop/platform/mac/SuperColliderAU/Source/SCProcess.cpp>
>>
>> Any idea?
>>
>> best,
>>
>> gerard
>>
>>
>>
>>
>>
>
>