Another go at a CDP frontend

[Xenakios]

Do you need any beta testers?

I'm presuming you have lua embedded in this now? If so, then it would be super cool if you enabled some kind of 'roll your own effects' feature.

Sure, beta testing will be needed once it is in a reasonably good shape. I just recently started working on a state history (aka undo history) feature which is a bit complicated one to do and has required changing some things that will need quite a bit more work to ensure they work properly...

Lua scripting has been incorporated into various things already. I have been thinking about doing the Lua audio data access thing too, but it might be a bit slow to access audio data on a per sample basis from Lua. (λ uses the official Lua C implementation, via the Sol2 C++ library. If LuaJIT still doesn't work on 64 bit macOS, it unfortunately isn't an option for me to use...)

Perhaps a compromise could be to allow doing higher order operations from Lua script code. For example, allow building DSP graphs from nodes like gain changers, panners, filters, delays etc...Also snippets of audio material from files could be scheduled for playing with various properties. (This actually is partially implemented in the Montage node already...I haven't tested what are the practical limits for the number/density of sound events in that though.)

[Xenakios]

As suggested by afta8, preliminary Lua script based DSP node...(At the moment good only for generating audio, but accessing audio files will be added shortly.)

[afta8]

Sweet!!!

Have you resolved the issue with accessing audio data? On Renoise the processing speed once the data is in the Lua side is quite fast, I don't think it uses LuaJit either, I run it on 64bit Mac Osx, I think the implementation is using LuaBind.. not sure if that makes a difference..

[Xenakios]

Sweet!!!

Have you resolved the issue with accessing audio data? On Renoise the processing speed once the data is in the Lua side is quite fast, I don't think it uses LuaJit either, I run it on 64bit Mac Osx, I think the implementation is using LuaBind.. not sure if that makes a difference..

The speed seems fairly decent even with per-sample accesses. (In the gif animation it generates 10 seconds of 4 channel audio in about 0.3 seconds, so about 30x real time and probably a bit faster too if the overhead of creating the buffer and writing it to disk wouldn't be taken into account.)

However, I suppose for a scripting environment it would be useful in any case to have a bit higher level operations available. So instead of multiplying or adding samples etc one by one, one would have functions like :

buf:multiplyRegionBy(startChan,endChan,startSample,endSample,gainFactor)
buf:addFrom(bufToAddFrom, startChan, endChan, startSample, endSample, gainFactor)
buf:applyEnvelope(startChan,endChan, {{0,0.0},{44100.0,1.0},{88200,0.0}})

(Those are just imaginary examples, the actual API would need to be designed more carefully.)

I did also add the disk file access into the scripted DSP node, but I think that should also do resampling of the audio into a target sample rate, so that the scripts don't need to bother dealing with that for simple use cases. (At the moment I just did a simple wrapping of the JUCE MemoryMappedAudioFormatReader.)

[Xenakios]

Just wanted to clarify here that this project has been suspended indefinitely, unfortunately. I got a bit too ambitious with it and got the code into a state where I wasn't able to proceed further. Of course I could go back in the Git history and restart from an earlier point, but the bigger changes I did were something I really wanted working anyway...