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 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