Maximize window = waveform expand

Submitted by G3N-es on
Forums
drumkv1

I've modified the .ui files (attached in waveform-expand.zip) for DrumkV1 and SamplV1 so that when the window is maximized, the waveform expands to its maximum. It's not only useful, but also aesthetically pleasing.

It would also be helpful if the "Elements" and "GEN1" had a QSplitter to further expand the waveform once you're focused on working with a specific element... but I haven't been able to achieve this yet.

Before:

After:

File attachments
after.png
before.png
waveform-expand.zip
splitter.png

Submitted by G3N-es on Mon, 7 Sep 2026 - 18:51

Permalink

The parameter titles have disappeared in my modification...
??
¿?¿?

I don't like web sites that reorder elements when I resize the window and I don't want to experience this with plugins.

I don't expect vanishing elements like the (for me) important list with flickering LEDs when I maximize the window.

So I don't like the idea at all.

@bluebell, did you test the new layout already?

it's pretty much the same as it ever was before, only that things stretch and scale a bit more nicely; maximizing the window doesn't change nor reorders the general layout, trust me.

the above is just a @G3N-es's proposal, it is not actually in place; besides the "maximized" version is about the splitter being manually brought to the left; you can bring it to right and expose the elements list in full to the right.

hyu.

Now I know that I can make the sample list vanish by moving the splitter to the left margin.

But then there is no sign that there is a hidden samplelist that can be reshown by moving the splitter to the right. Hovering over the splitter gives a small hint that there is something that can be moved.

@bluebell I understand your concerns, but that’s not the case here.

Modifications:

1_ The waveform now utilizes all available usable space when maximized:
Nothing changes position or gets hidden. The goal is simply to make use of the available space where it matters—for the waveform.

2_ Splitter bar:
The addition of a bar to hide either the GEN section or the Elements section follows this same logic. Nothing is hidden by default; the user decides how to organize their workspace based on what is most comfortable for the task at hand.

3_ New proposed layout change for GEN parameters.
Distributing the parameters across two rows instead of one offers several advantages:

  1. The waveform gains space even without maximizing.
  2. Mouse travel distance to access elements is reduced (a minor improvement, but an improvement nonetheless). It is also better organized: the first row is for waveform editing, and the second is for audio modification.
    The "Group" is essentially a MIDI control... and I think it belongs in the list: Element | Group | Sample... but it has always been located there.
  3. Maximizing not only provides more space for the waveform but also looks more aesthetically pleasing.

Drawbacks:
The height in the non-maximized state would increase... However, it should match PadthV1, so it isn't really a problem.

PS
Other proposals...
I have one more proposal I’m currently testing; it’s not difficult to implement (the fact that I’m testing it proves that), and I believe it vastly improves the workflow.

I want to make a video to present it to all you...

Video: https://github.com/G3N-es/shareMedia/raw/refs/heads/main/SelectElementByMIDI.mp4

Two things make working with DrumkV1 a hassle:

  1. Having to visually search the list every time you want to edit an element (it sounds trivial, but it’s irritating and wastes a lot of time when the process should be instantaneous, as I explain below).

  2. Thinking you’re working on a specific element when another one is actually selected, forcing you to undo your actions (loading a different preset, then reloading the one you were originally working on).

If this is implemented, the workflow becomes much faster, more intuitive, and more enjoyable—as shown in the video.

There’s no need to search for anything, and no risk of selecting the wrong preset.

The list essentially becomes unnecessary.

To-do:

  1. Naturally, this should be a configuration option—disabled by default—so no one is forced to work this way.

  2. Currently, the piano view displays the element selected via mouse click; it should simply show the currently selected element, regardless of how it was triggered.

And here is the code that works the magic:

pDrumkUi->setCurrentElement(key);

// drumkv1widget.cpp: line 1742

// Notification updater.
void drumkv1widget::updateSchedNotify ( int stype, int sid )
{
	drumkv1_ui *pDrumkUi = ui_instance();
	if (pDrumkUi == nullptr)
		return;

#ifdef CONFIG_DEBUG_0
	qDebug("drumkv1widget::updateSchedNotify(%d, 0x%04x)", stype, sid);
#endif

	switch (drumkv1_sched::Type(stype)) {
	case drumkv1_sched::MidiIn:
		if (sid >= 0) {
			const int key = (sid & 0x7f);
			const int vel = (sid >> 7) & 0x7f;
			m_ui.Elements->midiInLedNote(key, vel);
			m_ui.StatusBar->midiInNote(key, vel);

			pDrumkUi->setCurrentElement(key);   // <--- HERE!
		}
		else
		if (pDrumkUi->midiInCount() > 0) {
			m_ui.StatusBar->midiInLed(true);
			QTimer::singleShot(200, this, SLOT(midiInLedTimeout()));
		}
		break;

It’s that simple, and that powerful.

What do you think?

Submitted by bluebell on Wed, 9 Sep 2026 - 11:29

Permalink

  • The handle to enlargethe waveform window is visible. That's good.
  • I haven't understood what "selecing via MIDI" is. Does that mean that the parms of the currently played note are displayed?

You select the element by touching a MIDI note...

You play the note, and the element is selected.

You can...

  • Load the sample
  • Modify parameters, etc.

There is no need to search for the element in the list; it is selected automatically when you press the key.

You can quickly compare settings and edit on the fly while playing.

Have you seen the video?

  1. Both the video and the GIF show the incoming MIDI notes when the status bar messages aren't visible. You have looked at it, but you haven't seen it.

  2. The video shows how quickly I can adjust a Kit's parameters. It allows me to compare parameter differences—both by ear and visually—while editing on the fly.
    A task that took me 5 minutes would take at least half an hour using the Element List, simply because I’d have to visually hunt for the element by scrolling up and down, not to mention the frequent errors where you start editing a selected element that isn't the one you actually thought was selected.

  3. It doesn't run unless you want it to. I initially thought about making it a configuration option, but it actually makes more sense as a "Select by MIDI" button, since it acts as a selection and editing aid. There's no need to save its state in the settings; you just toggle it on when in edit mode and off when in play mode. It loads in the "off" state by default. It's even simpler to implement that way.

  4. There isn't even a performance drop—or if there is, it doesn't matter, since the feature isn't active during playback.

  5. You wouldn't recommend it? Why not? There are no downsides, only advantages. You didn't bother watching the video closely, let alone trying it out yourself... in a quick build. You'd only need to add one line of code to test the concept.

You simply don't like it, and that's that... fair enough. There's no arguing with personal taste.

If it must be switched on with a "Select by MIDI" button then I don't see any problems. I appreciate it.

In some cases it might be really useful. In other cases, e.g. having closed and open hihat on different notes in 1/16, it will be a mess :)

Chord:
It iterates through all elements in the order they were added.
You hear the result momentarily, and then press the note for the element you want to work on.

It is for EDITING, not for PLAYBACK.

I've implemented the button.

The button doesn't work in LV2; I have no idea why.

On the desktop version, relying on QObject::connect drastically affects performance.

Without the button, it works in both environments and performance is good, but it's designed for editing, not for live playing...
In fact, who plays back audio with the GUI open?

There must be a solution to these issues... that is the core concept.

And it can be tested with just two lines:

pDrumkUi->setCurrentElement(key);
activateElement();

And the concept is the difference between suffering while editing and enjoying it.

So, I maintain that the functionality is worth it.
It just needs to be made efficient.

Submitted by bluebell on Thu, 10 Sep 2026 - 05:59

Permalink

I find it useful, too. I was also editing the wrong instrument sometimes. Go ahead. Activating it with a "Use MIDI note on to select the instrument" button is a good idea, maybe a short name "Select by MIDI".

In gif...

You don't need to search for the item in the list to select it; MIDI selects it automatically.
I’ve done this without maximizing the window and with the list visible, so you can see it more clearly.
However, the list is no longer essential, so it is much more precise to edit the waveform maximize the window and do without the list.

File attachments
ingif.gif

Submitted by rncbc on Wed, 9 Sep 2026 - 18:07

Permalink

drumkv1 git head and in the same vein on samplv1 too.

please test and tell your thoughts.

cheers

ps. this will demand some new "official" screenshots, if accepted, so please take a deep breath ;)

Submitted by G3N-es on Wed, 9 Sep 2026 - 19:05

Permalink

I'm glad that, in the end, you both saw the advantages of this layout.

Thanks!!!

Tomorrow I'll run some tests and take some screenshots.

PS
I agree about the most visible points.

Submitted by G3N-es on Thu, 10 Sep 2026 - 20:30

Permalink

They have become a bit divas. What if that light doesn't favor me, what if I raise the focus, what if I don't bring the camera so close that you can see the circles under my eyes, what if a dress with QSS is not a dress.. Anyway, that's what it's like to work with the stars.

SamplV1 is angry with Drumkv1:
-Who do you think you are to have melodic instruments now?!!! He abruptly blurted out mid-session. The rest of us were shocked, except DrumkV1 who showed an expression of total indifference.

Well, they gave me the afternoon... but here are the photos.

With logo XD

PS
SamplV1 looks incredible now.

File attachments
drumkv1-maximized-XD.png
dumkv1-default.png
dumkv1_nolist-default.png
dumkv1_nolist-Teccnico.png
dumkv1-Teccnico.png
padthv1-default.png
padthv1-Teccnico.png
samplv1-default.png
samplv1-Teccnico.png
synthv1-default.png
synthv1-Teccnico.png

Add new comment

The content of this field is kept private and will not be shown publicly.

Markdown

  • Parses markdown and converts it to HTML.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type='1 A I'> <li> <dl> <dt> <dd> <h2 id='jump-*'> <h3 id> <h4 id> <h5 id> <h6 id> <img src alt height width> <strike> <pre> <p> <br>
  • Lines and paragraphs break automatically.

Filtered HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <b> <i> <pre> <img src alt height width> <strike>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
File attachments
Unlimited number of files can be uploaded to this field.
2 MB limit.
Allowed types: jpg jpeg gif png txt doc docx xls xlsx pdf ppt pps odt ods odp zip gz bz2 xz patch diff wav ogg flac ogv mp4 qtz.