[PD] julia

Spencer Russell sfr at media.mit.edu
Mon Aug 17 21:29:02 CEST 2015


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



Links:

  1. https://github.com/ssfrr/audioio.jl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150817/a403194e/attachment.html>


More information about the Pd-list mailing list