dspnode~.mxo causing Max crashing when Julia API functions are added to dspnode~.c #1
Comments
|
Could be worth creating a second branch. One branch demonstrating a successful build w/o Julia and a second the demonstrates the build that crashes. |
|
I am 75% sure this is down to how the The CMake file don't automatically add the library search path, link to the library or add the relevant compiler flags in in this instance I altered the build destination to Julia has it's own long list of instructions for embedding which may need to scrutinised more closely. |
|
In Which of course isn't ideal as After adding the above, now I'm getting a juliaDSP/source/projects/dspnode~/dspnode~.c Lines 88 to 95 in e98a777 |
|
I think a good first step, if you haven't already done this, would be to configure a simple C cli project in Xcode that consists of: #include <julia.h>
int main(int argc, char *argv[])
{
jl_init();
(void)jl_eval_string("println(sqrt(2.0))");
jl_atexit_hook(0);
return 0;
}that way it should help to narrow down what is a Julia problem and what is a Julia + Max problem. |
I've been able to build this just fine linking to libraries in an identical way to the It does fundamentally seems to be down to a Mach-O bundle (the |
|
I hate admitting defeat, so I snooped around the issues over at https://github.com/JuliaLang/julia and this one came across my eye: JuliaLang/julia#40246 This got me thinking that perhaps you've been doing everything correctly, it's the Julia
I altered the // registers a function for the signal chain in Max
void simplemsp_dsp64(t_dspnode *x, t_object *dsp64, short *count, double samplerate, long maxvectorsize, long flags)
{
post("my sample rate is: %f", samplerate);
jl_init(); // initialize julia, this in itself does not break anything
jl_value_t *ret = jl_eval_string("sqrt(2.0)");
if (jl_typeis(ret, jl_float64_type)) {
double ret_unboxed = jl_unbox_float64(ret);
post("sqrt(2.0) in C: %e \n", ret_unboxed);
}
else {
post("ERROR: unexpected return type from sqrt(::Float64)\n");
}
jl_atexit_hook(0);
object_method(dsp64, gensym("dsp_add64"), x, simplemsp_perform64, 0, NULL);
jl_atexit_hook(0);
}which will execute when you start the I think your only option for now is to embed the |
|
We are now in the same state: It appears any calls to julia in the audio thread ( Since the audio thread is time critical, if any calls to julia are happening on another thread it means you won't be able to use them directly. You may need to get a bit more clever about how you wish to interface with julia code via your external. |
|
I ran into the same problem with Julia 1.6; turns out that forcibly changing the working directory before So, yes: the audio thread is to be treated with due care. Strikes me that, in the end, you would probably want to have Julia compile expressions on a not-audio thread, and only do evaluation on the audio thread. That implies possibly using the Julia API at a lower level, in order to cache function pointers to compiled expressions. There's what seems to be an equivalent project for Supercollider here: https://github.com/vitreo12/JuliaCollider/ which might give some pointers on how to get Julia to play nicely in an audio context, and how to separate compiling from evaluating. |
Even a simple call such as evaluating print() causes Max to crash:
Something tells
console.app logs from the crash:
Full report
Click to expand
The text was updated successfully, but these errors were encountered: