As someone who’s always found the GUI thing hard work, it would really help to have a few GUI widgets and starter elements relevant to modern DAWs and plugins etc - in there that one can take - as well honed and designed basis for tweaking and buildig on - rather than reinventing the wheel again… badly
so… if not already in there - any chance of adding some stuff like piano roll widgets and other typical GUI elements that are more high level and music DAW focused than what JUCE already offers ?
The Tracktion Engine doesn’t have any GUI components, it’s purely about the audio engine and the data structures needed for that.
I suppose a case could be made for Juce itself to add things like a piano roll editor, breakpoint envelope editor etc, but those are rather involved things to have in a library. No matter how many customization points are added into such things, there’s always going to be something more people would want to look/behave differently.
Yeah, there’s a few reasons we don’t have any GUI components.
The first is that if we did, we’d just get a million clones of Waveform which kind of defeats the point of making the engine open source. The idea is people build their own app experiences and just use the engine for all the difficult low-level stuff.
The other is that for a library to include something as complex as a piano roll editor, it would either have to be tightly coupled to a model (such as the Tracktion Engine) or it would have to provide so many conversion points that it would be almost useless.
We don’t want to provide our own GUI components as that would mean it’s very difficult to change them. For example in W12 we added a bunch of new tools, and view modes such as fold etc. If that GUI component was in a library, it would have been really painful to do that and not break everybody’s code.
Plus, I don’t think there are “standard” ways of doing a piano roll. It very much depends on your feature set.
but we already kind of get that in many plugins and apps made with JUCE anyway - its often easy to tell where a developer has used JUCE because the widgets havent been embellished or customised to not look like JUCE widgets. So the same could apply to higher end stuff.
if well written - a basic piano roll core base widget or control-set could be visually customised to look, even behave more uniquely.
And if worried stuff will look like Traction - just made the high level widgets skinnable - and make the default skin and look in the engine library visually different to Traction itself
I really dont see this any different to how most of the cross platform libraries and IDEs all offer some kind of grid and listbox controls. And third party vendors offer more advanced customisable ones.
And in - for example the case of grid boxes - these can be customised to behave like spreadsheets etc - with a huge amount of properties to be customised - bit in look and behaviour. Just as every piano roll in every DAW looks differently and behaves differently ( or better or worse )
Of all the Wheels that dont need reinventing yet again - surely - imo - the piano roll has to be there for the music app dev…
We’ll it really depends on your feature set. Sure maybe a simple piano roll with just MIDI start/end point might be simple enough to put in a library but as someone who’s implemented one, trust me, there’s a lot of hidden complexity there. E.g. what’s your time base (beats/seconds), what does dragging a note start/end/middle do, how are you snapping move events - snap absolute/snap delta, is this different depending on the number of notes selected, does the editor have a notion of drawing looped notes, how does a copy/paste operation interact with the model, what position do new notes get pasted to, are there limits to the sequence, are you drawing MPE data, are groove templates applied, are notes quantised, is this a non-destructive operation etc. etc?
And that’s before we get on to velocities and CC data…
There’s just a huge amount to consider to get a working MIDI editor. The space of possibilities is just way way bigger than pretty much any widget JUCE offers. That’s why they’re so elegant, a list box might look complex to a user but there’s only a few virtual methods that need to be implemented to get that.
Maybe a piano roll editor is a good candidate for a community project. Unfortunately it’s just not a good candidate for something to live in Tracktion Engine I’m afraid.
Agreed. And all of that sort of thing has to be tackled by every DAW maker or developer of some thingamajig - plugin etc- that requires a piano roll.
Which is why - given one assumes your under the belly implementation is elegant, well evolved and properly refactored over years, well thought out … how much better to give us a really well engineered wheel - or mousetrap - that has all those elements but in a manner - modular maybe that can be customised as needed.
This is precisely why JUCE was born in the first place - only then it was to allow developers to get plugins off the ground without having to learn or get buried in all the under the hood complexities of plugin hosting and implementation.
Exactly the same rationale that gave us JUCE. applies to - yes extremely complex and variable - elements such as Piano rolls.
There is a flip side to this. I developed my own TracktionEngine based DAW precisely because I did not want it to be like other DAWs. I wanted a minimalist DAW that has only the features that I use, and nothing else. And this includes the piano roll. Even a generic built-in piano roll would almost certainly have features I don’t want or use. And, yes, my DAW has a minimalist piano roll.
IMHO TracktionEngine is different than JUCE. JUCE is a general programming environment. Whereas TracktionEngine is the foundation for building timeline based music apps. What you build on top of it is up to you. The separation of “inner workings” from GUI is actually a good thing.
In any case if dave96 would like to PM me - I’d be happy to take a look at the ( currently non-open-source ) relevant Traction source code and have a stab at seeing if I can engineer/refactor their piano roll stuff into something that addresses the points made in this thread.
I’d just like to give a bit of back-up to Dave on this one - I totally agree that a widget with enough functionality to be actually usable in a real app would be unworkably complicated to do in a generic way.
Probably the best we could do would be to provide a simple piano roll example to get people started, and then they’d hack and extend it to fit their needs.
There could be some non-GUI bits-and-bobs that we could provide to help with common tasks that are needed for this. E.g. a helper class to draw the ticks and time markers along the top, or classes to help map a mouse x,y to a note/time, etc.
But attempting to roll it all up into a GUI component that could actually fit into lots of use-cases without triggering a never-ending avalanche of feature requests… nope, sorry, not practical!
Yeah, if I was to create a new, simple piano roll editor specifically for use with Tracktion Engine I wouldn’t start with the 10’s of thousands of lines of the Waveform MIDI editor and try and trim it back.
I’d create a new demo app and build it up from there, similarly to how I’ve done with the step-sequencer demo. It mostly uses a juce::MidiKeyboardComponent for the vertical positioning of notes and a tracktion::engine::TimecodeDisplayIterator for the horizontal positioning (with a juce::ScrollBar to adjust the time range). Everything else is drawing, selection and modifying.
I suppose it might also be an idea for me or someone to do a kind of survey of any open source piano roll widgets - or implementations included in others juice project that might form the basis for the germ of what could become an extremely customisable control.
Personally the best piano roll editor GUI wise I’ve come across is Abletons. By miles. But it just lacks as we all know all the rich midi-editing type operations we find In the older DAWs but thats all non-gui midi processing so not really to do with any piano roll control.