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... _________________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Links: