A similar request to this was once posed in the thread below:
I am entering the final project phase of my Masters in Computer Science and would like develop a project with JUCE. I’m interested in going for DSP and Machine Listening/Learning type projects. I had an initial idea but sadly it’s fallen through due to previous research already existing and doubts that I would be able to develop any further on what has already been accomplished.
SO, I’m asking the JUCE community for any ideas on something people might think JUCE or plugin devs etc would really like to see.
I have to develop a project which tackles some problem/contributes a smidgen of original knowledge to my rather broad field (CS).
Does anyone have any thoughts on things the community is hankering for ? Whether it be some audio debugging facilities or whatever ?
I’d be most grateful to hear of anyone’s thoughts! It will be a fully documented project and something I’d would intend to make available to all on completion.
In the meantime I best get back to the idea cooker…
Alternatively a command line host like auval / vst 3 validator (http://vstdev.richackard.com/doc/vstsdk/applications.html) however it could be much more involved than either of those and of course be used to test multiple formats on multiple platforms. Maybe it could be designed such that it can take an input document (xml/json) of some sort that describes tests to run on the plugins? you could for example have it take an input audio file, an output audio file, a list of settings, a preset maybe, block size, etc. and check that the output file cancels when the input audio file is passed through the plugin using the settings/preset/etc.
Some sort of plugin analyser/“debugging” app is definitely on the list of possibles. An audio focused debugging front end could really interesting - hitting debug points for specific sample points (i.e. half way through a process block based on block sizes etc)… who knows.
If anyone else has ideas I’d still be grateful to hear them.
There is the Juce Package Manager project that @bazrush started and I’ve contributed to… seems neither of us has much free time to work on it atm but its something I’d like to get back to at some point, and I believe would be of much value to the community.
Unfortunately it wouldn’t involve much juicy stuff like machine learning or audio dsp… so might not be your bag. But if you’re interested please get in touch!
Thanks very much for the input. I’m not sure I can build an “Academically” sound research project out of the package manager.
However, I would definitely interested in looking into this as a side project anyway. I’ve been looking at building up more of a portfolio with some open source contributions so this might be just the thing. I’ll clone the repo of the initial JPM ideas next week and see whether I think I’m capable.
Cheers.
Once again if anyone else has any ideas grateful to hear them…currently at my desk with about 24 hours to go before I have to conjure up a project proposal! (gulp)
Hi Josh,
what I always wanted to do was a debug plugin host. Additionally to the juce plugin host I thought to have
a) switchable input channel / output channel configurations
b) having a set of different signal generators as inputs
c) displaying input and output waveforms
d) not running continuously but click for each processBlock calls, so you can see the waveforms and especially the boundaries, where the next block starts to find index errors
e) this probably is too much, but if you manage to add a step debug using LLVM/CLANG(?), so you can see, how single samples are computed, that would be heaven…
Just to throw some thoughts, maybe it triggers ideas for you.
Funnily enough I was thinking about that TextEditor problem this morning over a coffee …
If you do a debug host, it’d be really useful if it could repeat test automation and midi data and report if the output was different from a previously run. …
I haven’t had confirmation from the powers that be on my course to say whether the debug host is an acceptable project but it’s where I shall be spending my efforts as far as a contribution to the JUCE community is concerned. Suspect it’s not going to fly for my project supervisor but it will be my “free time” project I think.
I’d like to look into the package manager but for the moment the debug host is more up my street. I’ve taken everyone ideas on board. I think I’ll probably start fleshing out something with per process block breaks and graphical plots of buffer states and input output waveform displays etc. I’m thinking reverse debug stuff might be a good idea too to jump back in time inside a block or previous block.
I’ll get some ideas together over the next few weeks and maybe draw up a version 1.0 features list idea.
There’s a tool in my juce-toys folder called BufferDebugger https://github.com/jcredland/juce-toys that I wrote to help debug a pitch shifter. It might be of interest … or maybe not
Probably be taking a little inspiration from the project below as well but JUCEify things and add the likes of test signal generators and input-output displays etc.
Lots of ideas being thrown around for this by various people so I’ll start collating them over the next few weeks just as soon as I’ve knocked together this proposal for me course
Thankfully I’ve come up with an idea that has been deemed suitable!
