Experimental features discussion #6210
Replies: 11 comments 9 replies
-
|
You mention some that don't compile, but wait until #6204 is complete. The Theme Prefs was a tool for DIY builders who want to develop their own themes. It may still have value. The button that loads up the individual image files might offer a way to try out interactive development of images: use an image editor, reload into running Audacity, see how they all look in context, repeat. I don't remember what I was thinking about IMPROVED_SEEKING. November 2014? It was in the next year that I figured out the deeper hacks of the audio engine to allow scrubbing and seeking with mouse drags, which I considered technically successful, aurally, but we still have not yet put a satisfactory user interface on it. |
Beta Was this translation helpful? Give feedback.
-
|
re: theme prefs: Right, that'd be another use case. It feels to me like that theme prefs should become a non-enabled module then, so users who want to author themes can do so without necessarily needing to compile Audacity themselves. re: IMPROVED_SEEKING, it seems to me like the current scrubbing and seeking implementation sounds good, so the experimental change can get removed. |
Beta Was this translation helpful? Give feedback.
-
|
I think making a module of the Theme |
Beta Was this translation helpful? Give feedback.
-
|
One may ask why this needs to be a preference page and not just its own dialog. In fact a non modal dialog might be better, if you are trying out changes of images. Easier to do that that would just be to preview changes with a modal dialog button as with spectrogram settings. |
Beta Was this translation helpful? Give feedback.
-
|
it would be better as a dialog indeed. |
Beta Was this translation helpful? Give feedback.
-
|
If AUTOMATED_INPUT_LEVEL_ADJUSTMENT is worth experimenting with and keeping, it's also a little bit of a mess in the source code that demands some cleanup, and this waiting pull request #5830 to implement the per-track meters (rather a large request) also includes some of that cleanup, but would need rebasing now onto #6204 and some conflict resolution. |
Beta Was this translation helpful? Give feedback.
-
|
#6204 is now updated so all the Experimentals build, at least on macOS, I'm waiting for CI to build the rest. DeviceChangeHandler is the one with a lot of Os-specific branches and it was wrong for Windows in an earlier attempt. I don't promise that any of them work well for their old purposes and I don't mean to try hard to debug them. It should be confirmed, before merging this, that there are no unintended changes in menus. As explained at the PR, you will be forced by the compiler to keep the experimental branches up to date. The compiler will check and require correct source code in the disabled branches, but not really generate the code. |
Beta Was this translation helpful? Give feedback.
-
|
About EASY_CHANGE_KEY_BINDINGS, my idea was to let you navigate quickly to the binding of any given menu item. The preference page my be adequate to rebind any menu item, but you need to do a little bit of hunting for the right place in the trees. |
Beta Was this translation helpful? Give feedback.
-
|
I think that problem can be solved by a little reshuffling of the shortcut preferences: Have Name become the default and collapse the Tree option by default. If you have a specific name in mind, you'll be able to find it a bit faster in the names list as it'll be alphabetical, and if you have a certain location in the menu tree in mind, you'll also be able to find it faster as all the options in the tree you don't care about are collapsed. |
Beta Was this translation helpful? Give feedback.
-
|
MIDI stretch: to see the change of cursor, import a MIDI track, select a range of time in the track, and move the cursor toward the middle of the y-coordinate extend of the track. It's like a square with a cross-hair. Then click and drag left and right, to see changes in the duration of MIDI notes, shrinking on one side of the cursor and stretching on the other. I think the idea here was find tuned manual alignment of MIDI with audio, whereas the other Score Align experiment was meant to do it automatically over a whole track, but perhaps with some imprecision if there was some irregularity of tempo. |
Beta Was this translation helpful? Give feedback.
-
|
Find Notes and Y grid: I never tried these. I think they will only affect logarithmic scale view. The same contributor did make a contribution that was a bad idea that I removed years ago: b25994a It was a bad idea because it just aliased higher frequencies. |
Beta Was this translation helpful? Give feedback.
-
|
Track panel highlighting: see uses of Horrible saturated green and magenta! Try label tracks. |
Beta Was this translation helpful? Give feedback.
-
|
mmh, I've looked at them a bit now and I don't think they need hoverstates: Labels currently already look like floating textboxes, so they already communicate quite well that you can click into them and what will happen if you do. For envelopes, they have a custom cursor that communicates you can do something with the curve. There's one hoverstate they could do with, which is a hoverstate on the control points themselves so you know when you're touching those, as opposed to creating a new one. But then, a UI/interaction revamp of envelopes is something we want to do separately from that anyway. I think that flag can be removed. |
Beta Was this translation helpful? Give feedback.
-
|
That doesn't exhaust the places where this experimental changes appearances. |
Beta Was this translation helpful? Give feedback.
-
|
It doesn't but the story remains the same for them: it's hoverstates for too much at once (huge blocks of the UI as opposed to just the point that's being hovered over), or on features which I'd like to remove sooner or later anyway (such as the grabbers to the side of the multi-tool) |
Beta Was this translation helpful? Give feedback.
-
|
Scorealign: see "Synchronize MIDI with Audio" in the Tracks menu. I did the necessary code archeology to get this to compile. You need to select one or more audio tracks and exactly one MIDI track before it does anything. What it does, how well -- I have no idea. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe @rbdannenberg was using Audacity as a framework for his research?
|
Beta Was this translation helpful? Give feedback.
-
|
Automated input level adjustment: See checkbox menu item under Transport > Options |
Beta Was this translation helpful? Give feedback.
-
|
The build of #6204 has now reached unit testing for Windows and completed for all others. So have fun trying out the other experiments that did not build for you before. |
Beta Was this translation helpful? Give feedback.
-
|
The latest build failed on Windows because of timeout in unit tests. Retrying. |
Beta Was this translation helpful? Give feedback.
-
Paul is currently in the process of maintaining/repairing experimental code in #6204 and said:
I have to admit, I haven't paid attention what most of these do until now, so i tested them today:
CEE_NUMBERS_OPTION
This adds a preference to always use a decimal point, even in languages where a decimal comma is expected.
It was originally intended to fix bugzilla 2709, but that got a different fix in e80ec51.
A CEE option is pretty nerdy and not something I'd want, a more complete fix would introduce a new setting for locale (which governs number formats) in addition to language (which from then on would no longer govern number formats). #2518 is a relevant bug here.
SPECTROGRAM_OVERLAY
Spectrogram tracks indeed make sync lock difficult to see:
This implementation feels a bit like tail wagging the dog though: Sync lock (or any kind of selection, for that matter) also fails for very loud waveforms:
The solution here would be to draw the selection as an overlay over the waveform/spectrogram, instead of below it. The same is true for NOTETRACK_OVERLAY.
This experimental feature is trying to solve the problem from the wrong place, and can be removed.
THEME_PREFS
This setting reveals this lovely preferences page:
For the average user, this preference doesn't need to exist, it'd only be more confusing as the theme option (light, dark, etc) aren't in this window. So having it hidden somehow is appropriate - prime candidates would be doing it as a regular compiler flag (like ASIO) or as a module (like mod-script-pipe).
That said, the imageCache system of distributing themes is very easily broken. every time we add or remove buttons or colors, so we want to move away from that anyway. Whether it's worth porting the THEME_PREFS to a different method of enabling it, or just revamping the custom theme system such that all you need to do to distribute is to zip up the theme's Components folder remains to be discussed.
ROLL_UP_DIALOG
I'm not entirely sure what this is good for. It does something to ExpandingToolBar, which itself appears unused.
ExpandingToolBar brief
\brief A smart ToolBar class that has a "MainPanel" which is always
displayed, and an "ExtraPanel" that can be hidden to save space.
Can be docked into a ToolBarArea or floated in an ToolBarFrame;
If auto-expanding is off, behavior is very simple: clicking the
toggle button expands, clicking it again collapses.
If auto-expanding is on, behavior is a little more complicated.
When the mouse movers over a toolbar and it is collapsed, it gets
auto-expanded, and it gets auto-collapsed as soon as the mouse
leaves. However, if they manually toggle it collapsed
while it was auto-expanded, it will stay collapsed until you move
the mouse completely away and then back again later. If you
manually expand it, it will stay manually expanded until you
manually collapse it.
It'd be interesting to learn how expanding toolbar can be used. I'm eyeing the idea of having the different record modes and play at speed part of the normal play/record buttons somehow, and maybe that class could help with that. Also, this might be a solution for the contextual options for the brush tool (brush size and overtones).
Update: Upon further pondering, an expanding toolbar would come with the obvious downside of it messing with the layout, knocking the following toolbars into new lines and such. A floating toolbar, or a dropdown arrow next to the parent buttons would solve the same issue, and more nicely.
RIGHT_ALIGED_TEXBOXES
A very simple flag that sets wxTE_RIGHT instead of wxTE_LEFT for AddTextBox. This sounds more impactful than it actually is; in practice, most of our dialogs specify left alignment or center alignment separately anyway which overrides this.
VOICE_DETECTION (transcription toolbar)
Demo: https://www.youtube.com/watch?v=9ycvGF03zQE
Given that the openVINO tool does in one click what this tool needs 9 buttons and many more clicks for, I'd say there's no need for this to ever become mainline. It may be a candidate as a module which people optionally can install.
FIND_NOTES & FFT_Y_GRID
FIND_NOTES doesn't seem to do anything with either option enabled, FFT_Y_GRID doesn't compile.
The feature is somewhat nerdy anyway in that what you really want is a more general "audio to MIDI converter". I'm not principally opposed to a note grid as a spectrogram ruler, but given this option is ancient (2007) and not working, I'd vote to remove this one for now. #445 is a relevant bug.
SEEK_BEHIND_CURSOR
The functionality this promises should be enabled: Seeking should not be limited to from where you started playing (though it should not be allowed to start playing before t=0)
This flag doesn't seem to actually work currently though.
BRUSH_TOOL
From GSoC 2021, the functionality is quite cool, the UX isn't yet though.
This can be discussed together with ROLL_UP_DIALOG above, as that maybe gives us a tool to implement it more satisfactorily.nope, we'll need to find a different way.IMPROVED_SEEKING
It seems to me like it's a minor tweak to how seeking (pressing arrow keys during playback) sounds. I have no strong opinion on this. It certainly doesn't need to be carried as an experimental feature for all eternity. @Paul-Licameli Do you recall why this never got enabled?
Update:
The current implementation sounds good to me, the flag can be removed.
MIDI_IN
MIDI in is of course very interesting. Unfortunately it doesn't compile and even if it did, I don't have any MIDI input capability so I can't test whether it actually works and to what extent. This needs more investigation.
MIDI_STRETCHING
Also very interesting in principle. I unfortunately can't get the stretching to show up. Needs more investigation.
AUTOMATED_INPUT_LEVEL_ADJUSTMENT
As a noob-friendly option I don't hate it. I think it could be further improved: In Audio Setup, there could be an option which launches a wizard that listens to you on all devices, and then a) automatically selects the input device which gets any signal, b) auto-levels you and c) plays a sound on all output devices and asks you if you can hear it.
Doesn't compile on my system though.
METER_LED_STYLE
Discrete meters do have benefits over continuous ones in that you can count the number of lights you see to know the value, and having less movement as the quantized values change less often. This implementation however just puts a stencil on top of the meters which is neither aligned to dBs nor only shows discrete values. I don't think we need to keep that.
SCOREALIGN
scorealign -- a program for audio-to-audio and audio-to-midi alignment
scorealign works by computing chromagrams of the two sources. Midi chromagrams
are estimated directly from pitch data without synthesis. A similarity matrix
is constructed and dynamic programming finds the lowest-cost path through the
matrix.
The alignment can optionally skip the initial silence and final silence
frames in both files. The "best" path matches from the beginning times
(with or without silence) to the end of either sequence but not
necessarily to the end of both. In other words, the match will match
all of the first file to an initial segment of the second, or it will
match all of the second to an initial segment of the first.
Output includes a map from one version to the other. If one file is MIDI,
output also includes (1) an estimated transcript in ASCII format with time,
pitch, MIDI channel, and duration of each notes in the audio file, (2) a
time-aligned midi file, and (3) a text file with beat times.
That's one hell of an experimental feature. I can't judge the impact or usefulness of this yet.
DEVICE_CHANGE_HANDLER
Doesn't compile yet, but is something I'd like to see.
TRACK_PANEL_HIGHLIGHTING
I've been playing around with visuals in my themes branch and personally haven't missed not having a hoverstate on some of these options. I'll probably play around with them a bit in the future though.
DRAG_DROP_PLUG_INS
If this works well I have no objection to enabling it by default.
Update: For Nyquist this probably always works, for VST it may not. The ReaPlugs come with a Data folder, a JS folder and a few slider bmps.
EASY_CHANGE_KEY_BINDINGS
Bug aside, a shortcut to quickly make shortcuts feels very niche to me. Our shortcut preferences page is comparatively powerful already, letting you browse by menu, name and shortcut and also search. I don't see a strong need for this feature and don't recall any outcry when we disabled it. I'd say this can be removed.
Beta Was this translation helpful? Give feedback.
All reactions