Fixes#865. Added a check so we don't add subnotes to a note that is already released (can happen with very short midinotes, eg. sliding the mouse accross the gui piano).
I also added a mutex to incoming midievent handling in instrumenttrack. Not sure if strictly necessary, but seems like this would prevent problems in the long run.
Also fixed a glitch in noteplayhandle where silent master notes got stuck playing indefinitely ( isMasternote() returns true even if the nph just hadChildren, so it never gets ended if it did - instead we check if we still have subnotes).
There's no need to ever link a model to itself, allowing it can cause weird issues and crashes, plus it's easy to do by accident if you start a ctrl-drag and end it while still on the same widget
Apparently, we can use QBrush -typed properties in the CSS. This just never occured to me before!
So, this has several benefits. A QColor property only allows a singular RGB value, but a QBrush allows the same plus also qgradients, RGBA-colours and maybe even bitmap patterns. So I'm changing some properties to QBrush, where it makes sense to allow this additional functionality - no need to enable it for simple things like text colours or such.
- Song editor background: instead of the earlier hack with 7 qproperties just to set a limited background gradient, we can use only 2 properties and allow much more flexibility with Qt's own qgradient syntax
- Automation editor: background, graph colour, and the sidebar colour - @musikBear recently complained not seeing the grid through the graph, so transparency can help there, and qlineargradients in the graph can produce very cool visual effects. Grid is pointless to change, it should stay single-colour for now.
- Piano roll: here, I only made the background use QBrush - we don't really have much else here that can utilize QBrush, the notes have their own gradient system... maybe the 2nd colour of the note gradient could be customizable though.
There are probably more places where this change makes sense...
- This allows defining a default colour for BB-track patterns in the CSS
- The default colour is used for all bb-patterns which don't have a custom colour set by the user: in other words, the colour of a pattern can be any rgb-value OR "style colour"
- By default, all created bb-patterns use the style colour
- You can also reset colourized patterns to use style colour again
- Backwards compatibility: old projects will be loaded so that any pattern using either of the old default colours will be converted to use style colour
TODO: add a settings option that can disable custom colours (ie. always use style colour), and/or an option to reset all patterns in a project to style colour. This is needed, since themes can now change the song editor background, which can lead to unfortunate colour combinations with custom colours...
- currently only affects Vestige
- no idea whether this can also be used for Zyn and OpulenZ, I'm not sure if Zyn has any kind of mechanism for communicating frame offset to the synth, as for OpulenZ, @softrabbit would know the answer better
- basically, I made it happen by simply adding an extra parameter in the processMidi{In|Out} functions, which is 0 by default, and made the necessary changes in instrumentTrack and nph to utilize it
- I based this against 1.1 because I didn't think it's a very big change, and I don't see much possibility for things going wrong here, since we're basically just using the existing functionality in Vestige (there already was a frame offset being communicated to the remote plugin, just that it was always set to 0). However, if @tobydox thinks this is better to bump up to 1.2, I can rebase it for master...
- ctrl+alt+wheel changes q (as in auto)
- ctrl+shift+wheel changes note length
- changed note lock functionality slightly, it no longer changes itself to 1/16 because this would cause annoying infinite scrolling with the wheel, instead it just acts like 1/16 when notelength is last note
- entire wheelevent code was written very... weirdly, I simplified it
- fix bug with x zoom with mousewheel, no more getting stuck between 25/50
- ctrl+shift+mousewheel now zooms y-axis
- ctrl+alt+mousewheel now changes quantization
Basically, this works as such:
- if you click shift *after* starting a note move OR after creating a new note, the note move action is switched into resize mode, so you can quickly resize the note you just created, or the note you just moved. This saves time and improves workflow - at least based on my own experience: I've always wished I could do this, this is a huge time saving when you want to quickly jot down notes of differing lengths.
- if shift is already pressed when you click, the above will not happen, because that would mess with the note copy function. Copying notes with shift-dragging works the same as before.
- note test playback is halted when you click shift while moving. This is purely because it was causing some crackling noise, probably because of the changing length of a note that is currently playing. Maybe that can be fixed later, although it's arguably better not to hear the note while resizing - it's consistent with the other resize.
- works on group of notes as well, if you start moving a group of notes and then click shift, it will go into resize. Exception is notes copied with shift-drag... for obvious reasons.
- that should be all. Testing appreciated.
As of 6650dd356d base notes are not played
anymore when chords are enabled. Therefore create a separate NotePlayHandle
for the base note like we do for all other notes in the chord.
We don't want to loose the settings of an effect plugin even if it's not
available and thus can't be instantiated. Therefore remember original
settings data and save them back properly.
Partly closes#733.
Aka. 5-chord, simple 5th interval chord. A very simple addition and something I've always wondered why it's missing from the very extensive huge list of chords and scales.
Since we now provide the wavetables as pre-generated files, there's no delay caused by their initialization
so we can move it to the startup of the software. I thought engine.cpp is the best place for this, it makes
conceptually more sense than main.cpp IMO.
This way each instrument that wants to use them in the future won't have to call the initialization function
separately, making things a bit easier.
These methods are used to fetch the automated value of a model at a given MidiTime
These are still untested but that shouldn't be a problem since they aren't actually used by anything yet... but I'll be doing some testing and bugfixing (if needed) for them later.
These will be an important step in making sampletracks eventually be reliably playable from any position, and more generically, being able to reliably convert MidiTime to real time. Of course they can be useful for other things too (not sure what though, yet).
