BTW, for non-Julia coders, the method signature process{T <:
Real}(out::Vector{Vector{T}}, in::Vector{Vector{T}} means that process takes
two arguments in and out, each of which is a vector of vectors of type T, where
T is some subtype of Real.
The call to rand would probably also cause problems if T was an Integer
type, but hopefully this gives the jist.
-s
On Mon, Aug 17, 2015, at 03:24 PM, Spencer Russell wrote:
> Julia has a C-API so you can embed Julia the julia
> interpreter/compiler/runtime into other applications by linking
> against libjulia.so. It would be pretty doable to write a PD external
> that took a julia module as an argument and called an agreed-to method
> (like "process")
>
> So you could define a julia module
>
> module CoolNoise function process{T <:
> Real}(out::Vector{Vector{T}}, in::Vector{Vector{T}} for outvec
> in out for i in 1:length(outvec) outvec[i] =
> rand() * 2 - 1 end end end end
>
> and maybe the object would be called [jl~] so you could instantiate
> [jl~ CoolNoise] and it would use your julia code to process blocks
> of audio.
>
> I haven't thought much about whether this is the *best* way to do it,
> but it would work. You'd need some other stuff in there to report back
> the number and type of inlets/outlets, and probably some other stuff.
>
> There are a few gotchas to writing latency-sensitive code in Julia,
> particularly because it's garbage-collected so you want to be careful
> not to write code that ends up doing a lot of heap allocation, but
> there's been some work on the GC to speed it up, and in particular an
> incremental GC that will yield control if the GC exceeds a time limit.
> I've talked a bit to the guy working on it and while the current
> version doesn't include his incremental code I think that with a
> little encouragement (maybe a bottle of nice whiskey) he could be
> persuaded to make it a reality. Aside from GC the other issue is that
> that JIT compiler is a double-edged sword. Once things are compiled
> they're really fast, but the process of compiling happens the first
> time a method is called, so you need to make sure that any audio
> methods you define get compiled before the main audio loop starts up.
> Julia is also not thread-safe yet, though there are folks working on
> it, so calling into julia code from multiple threads is a recipe for
> segfaults.
>
> I wrote and maintain the AudioIO.jl[1] package which is an interactive
> signal processing framework for Julia so I've spent some time thinking
> about some of this. The project has lagged a bit while I've been
> finishing up my (unrelated) masters thesis but this fall I'm going to
> be digging much more deeply into it. I've actually considered
> implementing the PD C API so I can pull PD externals into Julia,
> basically the inverse of this.
>
> -s
>
>
> On Mon, Aug 17, 2015, at 02:38 PM, Forrest Curo wrote:
>> Any chances of adding Julia to the available languages for writing pd
>> extensions? It seems to combine much of the writability of python
>> with the specificity & machine-concreteness of C...
>> _________________________________________________
>> [email protected] mailing list UNSUBSCRIBE and account-management
>> -> http://lists.puredata.info/listinfo/pd-list
>
Links:
1. https://github.com/ssfrr/audioio.jl
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
