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...
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:
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:
On 08/17/2015 09:24 PM, Spencer Russell wrote:
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.
hopefully, there will be *no* wrapper object, and you can instantiate [CoolNoise~] directly (or at least [CoolNoise], if ~ makes problems in julia)
gfmards IOhannes
My thought was that a wrapper object would be something that interested parties could put together on our/their own to get the language interface figured out, and then if it turned out that it worked well and people liked it then it could be integrated more tightly.
-s
On Mon, Aug 17, 2015, at 03:47 PM, IOhannes m zmölnig wrote:
On 08/17/2015 09:24 PM, Spencer Russell wrote:
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.
hopefully, there will be *no* wrapper object, and you can instantiate [CoolNoise~] directly (or at least [CoolNoise], if ~ makes problems in julia)
gfmards IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list Email had 1 attachment:
- signature.asc 1k (application/pgp-signature)
On 08/17/2015 09:59 PM, Spencer Russell wrote:
My thought was that a wrapper object would be something that interested parties could put together on our/their own to get the language interface figured out, and then if it turned out that it worked well and people liked it then it could be integrated more tightly.
ah i was a bit terse: Pd (since 0.40) provides a "loader" mechanism in it's public API, that allows to write well, loaders that implement e.g. language bindings.
it's about the same amount of work to write a loader or an object (the hard part is the language binding; the rest is just glue) - so one should start with writing a loader right away.
see the loaders in externals/loaders/ [1]; "hexloader" and "import" should be pretty simple to understand ("pdlua" resp "tclpd" are probably too full of the actual language bindings).
gfmards IOhannes
On Aug 17, 2015, at 5:55 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 08/17/2015 09:59 PM, Spencer Russell wrote:
My thought was that a wrapper object would be something that interested parties could put together on our/their own to get the language interface figured out, and then if it turned out that it worked well and people liked it then it could be integrated more tightly.
ah i was a bit terse: Pd (since 0.40) provides a "loader" mechanism in it's public API, that allows to write well, loaders that implement e.g. language bindings.
Very cool! I wasn’t aware of that feature. Do you know where I can find docs for it?
-s
-
Forrest Curo -
IOhannes m zmölnig -
Spencer Russell