Output combo boxes for Jack driver #7919

michaelgregorius · 2025-05-31T16:52:55Z

Implements #7918 and additionally provides an input configuration so that feature-wise it becomes on par with the SDL driver dialog which already provides an input selection as well although the feature itself is not implemented yet.

Here's what the feature looks like:

The dialog mirrors the technical input/output names that are used for the JACK ports.

It's possible to leave an input/output disconnected by selecting the "-" option.

Add two combo boxes and a Jack client to the Jack setup dialog. The combo boxes display the available Jack inputs. Please note that in Jack terminology these are called "outputs". The own Jack client is necessary because the setup dialog does not have any access to the actual driver. So a new client is created when the dialog is opened and deleted when it is closed, i.e. when the dialog is deleted itself. The available inputs are collected via `AudioJack::setupWidget::getAudioInputNames` and are then put into the combo boxes via `AudioJack::setupWidget::populateComboBox`. `AudioJack::setupWidget::saveSettings` saves the selections that have been made in the combo boxes into the configuration. Add the method `handleRegistrationEvent` to `AudioJack` and register it in `AudioJack::initJackClient` via `jack_set_port_registration_callback`. Currently it will only output information about the port via `printf` but not do anything else. It can likely be removed again because the `AudioJack::setupWidget` uses it's own client and must register its own callbacks in case it wants to react to changed inputs and outputs while the setup dialog is open. * Do the same for the inputs * Read the information stored in the configuration when the driver is initialized. Gracefully handle when selections are not available, e.g. because the device is not plugged in. * Decide if the setup dialog should react to changed ports while it is open. This might complicate selections that are currently made, i.e. it has to be ensured that the user experience is good. * Remove printf statements

Extend the Jack setup dialog with combo boxes that present the available outputs. Save the selected outputs in the configuration. Add `AudioJack::setupWidget::getAudioPortNames` which takes the type of port and then collects all port names which match. Make the new `getAudioOutputNames` and `getAudioInputNames` delegate to that method with the appropriate type. This also hides the different terminologies a bit.

Attempt to reconnect the inputs and outputs from the configuration during startup of the Jack driver. Nothing will be done for inputs and outputs that are not available at startup. Example: the users might have saved some inputs when a device was available. The device is then disconnected and LMMS restarted. The stored inputs cannot be used anymore. To give the users the least surprise nothing is done. `AudioJack::attemptToConnect` does the actual reconnection and also prints some information for now. `attemptToReconnectOutput` and `attemptToReconnectInput` delegate to `attemptToConnect` with the right parameters.

When populating the combo boxes select the current input/output as saved in the configuration.

Show a warning message in the Jack setup dialog if some inputs or outputs that are set in the configuration are missing in the system. This might for example be caused by disconnected devices. Let `populateComboBox` return a boolean which indicates if the selected port can be found in the list of displayed ports or not.

Remove `AudioJack::handleRegistrationEvent` as it was only used for debugging so far.

Replace repeated hard-coded strings with references to static constant variables in the anonymous namespace. This should prevent subtle mistakes when working with the configuration values of the Jack driver.

Input selection does not make sense for master now because recording is not implemented/merged yet. However, being able to select the inputs from a combo box instead of having to use an external connection manager already brings benefit to users. Hence we remove input selection for now. There will be a separate branch/commit which will revert this commit, i.e. which will add input selection again once it makes sense for master.

Introduce input selection for the Jack driver similar to how it is done for the outputs, i.e. saving to configuration, reconnection at driver start, etc.

Present the available inputs and outputs in a hierarchical sorted menu which shows clients with their ports. The heavy lifting of creating the menu for the tool button is done in the new method `buildMenu`. It takes the input/output names in Jack's "Client name:Port name" format. If an input/output name can be successfully split into the client name and port name then a sub menu with the client name is created (if it was not already created before) and the port name is added as an entry. If the name cannot be split into exactly two components then it is simply added to the top level menu as is. Ports of the LMMS client are filtered out to prevent loops. The menu starts with the client's sub menus in alphabetical order. Then the top level entries are added in alphabetical order as well. The callbacks for the `QAction` instances are implemented with lambdas because MOC does not support nested classes like the setup widget is. For now the used lambda only sets the text of the `QToolButton` as these are used for persisting the configuration anyway. Replace the `QComboxBox` instances with `QToolButton`.

JohannesLorenz · 2025-06-03T21:41:06Z

I made a few tests. Some first points I noted:

You can change the outputs, but it only has an effect after restarting. This also reflects what your code is doing: The connect stuff is called in startProcessing. I would have expected that this could be done while LMMS is running, since qjackctl allows reconnecting between existing jack apps all the time.
Jack output ports can be connected to more than one input port at a time. The LMMS dialogue makes it look a bit like you only have one choice. Thinking more about it, it means LMMS stores a canonical connection out of possibly multiple ones. So this PR's implementation is perfectly valid, I just wanted to mention this.
When you have LMMS running, meanwhile change the connections using qjackctl, and then restart LMMS, on startup, it will indeed override your connections. This seems rather wanted to me - it makes sense that it remembers what I selected instead of using defaults.
Your dialogue makes it possible to connect LMMS' output to its own input. qjackctl also allows this. In practice, however, I guess this makes sense to remove from the ComboBox?
You see "Output 1" is connected to Left and "Output 2" to Right speaker, but what does 1 and 2 mean? In Jack, output ports have names (same like input ports), so it would be better to display those names than "Output 1", "Output 2" IMO.

michaelgregorius · 2025-06-06T15:04:28Z

Thanks for checking @JohannesLorenz!

Regarding your observations:

You can change the outputs, but it only has an effect after restarting. This also reflects what your code is doing: The connect stuff is called in startProcessing. I would have expected that this could be done while LMMS is running, since qjackctl allows reconnecting between existing jack apps all the time.

That's a fundamental shortcoming of the current SetupDialog implementation. It does not get any "business" data to work on. It only gets the tab that should be opened initially and then operates on the static ConfigManager instance. This means that it only operates on the configuration which to my knowledge is only read when LMMS starts. Hence if you make any changes to the configuration you must restart LMMS for the changes to take effect. Below I have described some potential fixes which are outside of the scope of this PR though.

Jack output ports can be connected to more than one input port at a time. The LMMS dialogue makes it look a bit like you only have one choice. Thinking more about it, it means LMMS stores a canonical connection out of possibly multiple ones. So this PR's implementation is perfectly valid, I just wanted to mention this.

Yes, it is assumed that there are some main outputs/inputs. More complex setups would have to be created with a session manager because IMO it does not make sense to implement a full-fledged session manager with all possibilities in LMMS. 😅

When you have LMMS running, meanwhile change the connections using qjackctl, and then restart LMMS, on startup, it will indeed override your connections. This seems rather wanted to me - it makes sense that it remembers what I selected instead of using defaults.

Yes, it is intended as a default setting that is reestablished on each start.

Your dialogue makes it possible to connect LMMS' output to its own input. qjackctl also allows this. In practice, however, I guess this makes sense to remove from the ComboBox?

The LMMS client is already filtered in my local branch that's shown in #7918 (comment). It has some further improvements like for example grouping by Jack client, sorting, etc. I wonder if I should ditch this PR, push the changes from the comment into #7920, make that PR the main one and comment/define out everything related to inputs. This would mean that if recording is merged the inputs could be reinstated quickly.

You see "Output 1" is connected to Left and "Output 2" to Right speaker, but what does 1 and 2 mean? In Jack, output ports have names (same like input ports), so it would be better to display those names than "Output 1", "Output 2" IMO.

Do you mean the labels? IMO they should not change according to the selection. However, your comment made me come to the conclusion that it might be better to change the labels to "Output L", "Output R", "Input L" and "Input R".

What do you think?

Potential fixes for the Setup Dialog

There are several options to fix the restart problem of the setup dialog:

Provide the setup dialog with access to the data that is affects, like for example driver classes, etc., so that it can immediately act on some things
Make the ConfigManager emit a signal when the configuration has changed and let interested consumers react to that.

JohannesLorenz · 2025-06-06T19:23:56Z

Your dialogue makes it possible to connect LMMS' output to its own input. qjackctl also allows this. In practice, however, I guess this makes sense to remove from the ComboBox?

The LMMS client is already filtered in my local branch that's shown in #7918 (comment). It has some further improvements like for example grouping by Jack client, sorting, etc. I wonder if I should ditch this PR, push the changes from the comment into #7920, make that PR the main one and comment/define out everything related to inputs.

I don't have a strong opinion here. Though, this remark of mine (numbered "4") was a very minor observation, so it does not need to give rise to change the branching strategy.

You see "Output 1" is connected to Left and "Output 2" to Right speaker, but what does 1 and 2 mean? In Jack, output ports have names (same like input ports), so it would be better to display those names than "Output 1", "Output 2" IMO.

Do you mean the labels? IMO they should not change according to the selection. However, your comment made me come to the conclusion that it might be better to change the labels to "Output L", "Output R", "Input L" and "Input R".

What do you think?

I mean, in qjackctl, you will see that the LMMS client has 2 output that you can connect to other client's inputs. The input port names are in your Combo box, and they have the same names as in qjackctl. However, the output ports should IMO be left to the ComboBox, in the same way as in qjackctl.

So, if qjackctl shows you

     +--------+                             +-----------+
     |  LMMS  |                             |  Speakers |
     |        |                             |           |
     |        | out_1  ------------------>  in_1        |
     |        | out_2  ------------------>  in_2        |
     +--------+                             +-----------+

Then LMMS should IMO show you the setup dialogue as

out_1:    in_1 v
out_2:    in_2 v

(The v marks the combo box dropdown arrow, excuse my drawing skills). So here, we use exactly the names that the output ports have in qjackctl.

Potential fixes for the Setup Dialog

There are several options to fix the restart problem of the setup dialog:

Provide the setup dialog with access to the data that is affects, like for example driver classes, etc., so that it can immediately act on some things

Make the ConfigManager emit a signal when the configuration has changed and let interested consumers react to that.

I think there may be another solution. AudioJack already knows its own ComboBoxes, which means it can use the signals of them and connect them to callbacks of its own. (At that point, I am not sure if reconnecting must be done inside a realtime thread, but no matter, this seems better than restarting).

JohannesLorenz

Finished 1st review:

Checked code
Checked style
Tested

include/AudioJack.h

src/core/audio/AudioJack.cpp

Let the tool buttons stretch so that they look uniform and use all the available space.

Remove the printing of the audio port names in `getAudioPortNames`.

Show the technical output and input port names used by LMMS in the setup dialog. Note: these are the names that are shown in tools like `qjackctl` or `qpwgraph`. This was proposed in a review. Personally I like the non-technical names better but let's see what's accepted.

Switch the popup mode of the tool buttons from `MenuButtonPopup` back to `InstantPopup` so that users can click everywhere. This works better now because the buttons use all the space and the little triangle can be seen better.

Make CodeFactor happy.

michaelgregorius · 2025-06-14T16:01:20Z

@JohannesLorenz: I have merged the changes of the now closed PR #7920 into this PR. The rationale is that the SDL driver dialog already sports input selection as well although the feature itself is not implemented yet.

Here's what the feature currently looks like:

The dialog now also sports the technical Jack output/input names. I am not a big fan of that but let's see what's the option of others.

In case the input selection should be hidden until the feature is implemented then this could be done with a handful of #ifdef statements.

michaelgregorius · 2025-06-14T19:07:14Z

Moving some of the discussion here so that we are not confined to that small code review discussion.

Sorry, I cannot follow. Might be the heat :) Tracks end at Mixer channels, and those go to master. Why allowing a track to bypass the mixer?

Yes, it was much too hot today. 😅

It can give great flexibility if one is allowed to route the output of one or more tracks into another track (as long as there are no feedback loops I guess). For example here are the options that are provided for the output of a track in Bitwig:

In this example the output of track "Audio 2" is routed to the track "Audio 3". As can be seen in the menu it is even possible to route it to other applications which should come natural for a PipeWire or Jack driver.

In general it is for example also possible to route track A, B and C to track D, enable recording for D and then create a quick bounce while doing so and then to continue working with that new sample. I assume that this is not possible in LMMS if it routes tracks to the mixer with no other options.

Another use case could be to create effect tracks/busses by routing tracks accordingly.

Also, given the last paragraph, why wait and not already implement the final solution?

Because it's a very huge undertaking. 😅

One would have to implement some kind of interface which would provide at least the following functionality:

Provide access to all available inputs and outputs (or their buffers) during a period. This would likely need to be done using a separate "staging" area where drivers provide/copy their buffer contents as an LMMS defined sample format. LMMS would then use the buffers as the sources while traversing the audio graph.
Handle and report devices/ports that appear or disappear during runtime.
Abstract devices and ports and their naming, etc.
All or some of the functionality must work in a thread-safe way. If a track is connected to an input then the track must be able to handle the case of that input disappearing, e.g. because the user has turned of a device during playback.

That interface would need to abstract lots of the stuff provided by the different drivers and provide it in a uniform way to LMMS' code.

All drivers would be affected by that design change because every driver would need to cater to that interface as good as possible, e.g. each driver would need to map its own inputs and outputs to the inputs and outputs provided by the staging area. Each driver would need to copy its buffers to the staging area, etc.

The interface would also need to be designed in such a way that everything still works even if some drivers cannot provide all features. It might for example be the case that some drivers do not allow for devices to appear or disappear during runtime.

Because its a large undertaking this PR only intends to (slowly) move towards this direction by providing some rudimentary routing functionality which can then be used by the also rudimentary sample recording functionality/branch.

Generalize the number of inputs and outputs by using for loops. This affects the number of widgets that are created and the amount of configuration that is stored. This change is a result of a code review discussion. In my opinion it adds unnecessary complexity to something that should later be implemented completely different anyway. It is for example now necessary to compute the key names that are used during the saving of the configuration based on the channel number. The commit exists so that its changes can be discussed further. It might be reverted in one of the next commits.

JohannesLorenz

Code and style OK

src/core/audio/AudioJack.cpp

bratpeki · 2025-06-24T18:14:53Z

Okay, ran it now. I feel like setting both the L and R is a bit overkill. Also, most input devices will be microphones, which are mono. The mono thing isn't that bit of an issue, TBH, you just set the mono signal to be both the left and right input. But still, what's your opinion on someone needing to set both the L and R?

I feel like the mapping should be automatic and be like:

Pick a stereo item -> L:L, R:R
Pick a mono item -> L:M, R:M

Let's start from that.

bratpeki · 2025-06-24T18:24:07Z

Needs a restart, but works!

michaelgregorius · 2025-06-24T18:33:41Z

Okay, ran it now. I feel like setting both the L and R is a bit overkill. Also, most input devices will be microphones, which are mono. The mono thing isn't that bit of an issue, TBH, you just set the mono signal to be both the left and right input. But still, what's your opinion on someone needing to set both the L and R?

I feel like the mapping should be automatic and be like:
* Pick a stereo item -> L:L, R:R

* Pick a mono item -> L:M, R:M
Let's start from that.

Jack does not have a concept of mono and stereo channels. Therefore heuristics would have to be used to get an idea of which channels might belong together and form a stereo pair. Therefore I think this should be something for a later improvement down the line.

bratpeki · 2025-06-24T21:19:58Z

Alright, thanks for elaborating! I'll test it some more and approve when I'm happy.

As you can see from the QJackCtl graph, it seems to work great!

messmerd · 2025-06-24T23:32:00Z

The pin connector from #7459 might be a good fit for selecting JACK outputs and routing to them, though if we wanted to try that, it could probably be done later to avoid holding up this PR.

The benefit would be more flexible routing, support for JACK outputs with any number of channels, and the same familiar pin connector UI used by instruments and effects.

michaelgregorius · 2025-06-27T14:49:04Z

The pin connector from #7459 might be a good fit for selecting JACK outputs and routing to them, though if we wanted to try that, it could probably be done later to avoid holding up this PR.

The benefit would be more flexible routing, support for JACK outputs with any number of channels, and the same familiar pin connector UI used by instruments and effects.

The pin connector goes into the direction that i have already alluded to in some comments for some other PRs. In the mid/long term the configuration options should be removed from the driver dialog and moved into the tracks. The pin connectors would allow the users to do so.

The pin connector would have to work with all available drivers which have different capabilities. So the pin connector will likely have to work on some internal LMMS representations instead of a specific Jack/PipeWire implementation. However, it seems that this is already handled by your PR.

bratpeki · 2025-07-09T14:14:32Z

Okay, I'm back!

Tested again, works flawlessly! AFAIC, this can be merged immediately, maybe minus the debug messages on the terminal, but then again, those might also be useful, so no real reason to drop them.

Maybe consider adding a "None" option in the dropdown, in case someone doesn't want to specify some input, but if the user doesn't need an input, they can just specify whatever, LOL!

Output the success/failure messages with regard to the reconnects only in debug builds.

Add the option to keep inputs/outputs disconnected. The disconnected state is represented by the string "-" which is also what is saved into the configuration in this case. For now the representation in the GUI and of the save state is the same as it has the advantage that no translation is necessary and thus not mapping between display text and save state is necessary.

Make the output unconditional again because it interfered with some release builds. They complained that the `result` variable in `AudioJack::attemptToConnect` was unused because it was only further used in debug builds. The alternative would have been to duplicate the `jack_connect` call. However, that would have been a worse solution because it would have duplicated critical code which might have deviated due to the duplication.

bratpeki · 2025-07-09T15:19:11Z

Cool! Imma wait for the builds to finish and retest.

michaelgregorius · 2025-07-09T15:19:38Z

Okay, I'm back!

Thanks for testing, @bratpeki!

Tested again, works flawlessly! AFAIC, this can be merged immediately, maybe minus the debug messages on the terminal, but then again, those might also be useful, so no real reason to drop them.

With commit b04ff1b I have attempted to make them output only in debug builds but that lead to some problems with the release builds. So I reverted the changes in commit e270c71.

Maybe consider adding a "None" option in the dropdown, in case someone doesn't want to specify some input, but if the user doesn't need an input, they can just specify whatever, LOL!

Commit 776d0be adds a disconnected state in the form of a "-" entry at the end of the list. 🙂

Can you please do a final test with regards to the new option? I would then merge after that.

bratpeki · 2025-07-10T06:05:23Z

I'll be able to do that next week, probably on Tuesday 🫡

bratpeki

Works great!

michaelgregorius · 2025-07-16T20:03:01Z

Works great!

Happy to hear that. 😃

I will merge then. Thanks for testing this again!

AW1534 · 2025-08-02T16:27:54Z

This PR seems to have caused an issue for me in which LMMS consistently segfaults upon opening settings. I am on Debian testing.

stack trace:

The latest nightly AppImage experiences this issue, but the AppImage directly before this PR doesn't.

AW1534 · 2025-08-02T16:49:19Z

@irrenhaus3, who also experienced this issue, figured out that installing JACK2 fixes the segfault. However, if jack isnt running, the PR introduces a little stutter of maybe half a second when opening the settings menu which is slightly annoying

I think this happens if your system uses jack1 instead of jack2 and jack is in fact not running - maybe getAudioPortNames() attempts to connect to the jack instance and null-derefs if there is none. If you're running jack2 it will just try to connect to the daemon and come up with an empty list after the timeout expires.

I experienced the same thing and was able to fix it by installing jack2, but I didn't look into it much deeper

michaelgregorius · 2025-08-02T17:43:26Z

This PR seems to have caused an issue for me in which LMMS consistently segfaults upon opening settings. I am on Debian testing.

stack trace:

The latest nightly AppImage experiences this issue, but the AppImage directly before this PR doesn't.

Edit: fixed with pull request #8026.

@AW1534, following through with #7659 I have finally archived my LMMS working copy. However, I can try to assist with some fix. It seems that you are in a better position to reproduce the bug anyway because I have always activated JACK via PipeWire and don't want to muck around with a working Linux audio system. 😅

Can you please check the state of m_client in AudioJack::setupWidget::getAudioPortNames when you run into the problem? If it is nullptr it might suffice to change the code to

std::vector<std::string> AudioJack::setupWidget::getAudioPortNames(JackPortFlags portFlags) const
{
	std::vector<std::string> audioPorts;

	if (!m_client)
	{
		return audioPorts;
	}

	const char **inputAudioPorts = jack_get_ports(m_client, nullptr, JACK_DEFAULT_AUDIO_TYPE, portFlags);

	[...]

If it is not nullptr then I wonder if it is rather a problem with weak_libjack which seems to wrap the underlying JACK implementation (https://github.com/x42/weakjack).

I assume that the problem with the stutter is also rather caused by the underlying libraries as I have not implemented some explicit waiting in case the server cannot be reached.

michaelgregorius · 2025-08-03T10:35:36Z

Ok, so I have installed Debian in a virtual machine and have fixed the bug with pull request #8026.

michaelgregorius · 2025-08-06T16:19:54Z

This PR seems to have caused an issue for me in which LMMS consistently segfaults upon opening settings. I am on Debian testing.

@AW1534, this is now fixed in the current master. Thanks for bringing the problem to my attention!

messmerd

This is the first that I've looked at this PR's code.

While this is by no means a thorough review, there are some functional issues that immediately jump out at me, plus some breaks with the style guidelines.

And it appears the PR title and description are inaccurate, and the screenshot out-of-date? Because there are input selection combo boxes too.

messmerd · 2025-08-06T16:50:35Z

src/core/audio/AudioJack.cpp

+	}
+
+	auto outputName = jack_port_name(m_outputPorts[outputIndex]);
+	auto targetName = targetPort.toLatin1().constData();


The .toLatin1() method creates and returns a QByteArray by value, then its .constData() method returns a const char* pointer to its internal buffer. But the QByteArray is a temporary and will be destroyed at the end of this statement, so targetName becomes a dangling pointer.

It does not really seem like a problem to me because the pointer is not really "dangling". The pointer value of targetName is passed as a parameter into the attemptToConnect method which does its job and does not store the value in any way. I assume that jack_connect doesn't store it either.

Because the value of targetName is not stored anywhere or returned to the caller it does not really have the character of a dangling pointer to me. It shouldn't create a memory leak either, because as you have noted toLatin1 returns a value which is destroyed at the end of the method. Therefore everything should be good and clean at the end of attemptToReconnectOutput.

Or am I missing something here?

This is not about whether it's an owning raw pointer or whether the function it's passed to stores it. This is about the pointer being used after the lifetime of the data it points to ends.

Like all containers, QByteArray uses RAII to clean up the data it contains when it goes out of scope. And just like std::vector<T>::data() and std::string::c_str(), QByteArray::constData() returns a non-owning pointer to the internal data the container manages. That pointer is only valid for as long as the data it points to is valid.

In this case, the temporary QByteArray goes out of scope at the end of line 258, and although QByteArray is copy-on-write, its reference count would be 1 when it goes out of scope so the data will be deallocated by the destructor.

So by line 260 where targetName is used, it is a pointer that points to memory that is no longer valid - a dangling pointer - so dereferencing it and using it is undefined behavior.

Ah, you're right. For some reason I believed that the temporary would live until the end of the method which of course it does not. I have opened pull request #8032 which fixes this problem.

messmerd · 2025-08-06T16:50:49Z

src/core/audio/AudioJack.cpp

+	}
+
+	auto inputName = jack_port_name(m_inputPorts[inputIndex]);
+	auto sourceName = sourcePort.toLatin1().constData();


See my reply here: https://github.com/LMMS/lmms/pull/7919/files/e270c7178f2d9ec32793c19b78470a2a21b07e6d#r2258006326.

messmerd · 2025-08-06T16:54:52Z

src/core/audio/AudioJack.cpp

+static QString buildChannelSuffix(ch_cnt_t ch)
+{
+	return (ch % 2 ? "R" : "L") + QString::number(ch / 2 + 1);
+}
+
+static QString buildOutputName(ch_cnt_t ch)
+{
+	return QString("master out ") + buildChannelSuffix(ch);
+}
+
+static QString buildInputName(ch_cnt_t ch)
+{
+	return QString("master in ") + buildChannelSuffix(ch);
+}


Why have static functions here when you added an anonymous namespace block just a few lines above?

Should the strings here be translated using QObject::tr()?

Why have static functions here when you added an anonymous namespace block just a few lines above?

IIRC, I did this because the ch_cnt_t type is "LMMSy" and therefore I have put it into the LMMS namespace.

Should the strings here be translated using QObject::tr()?

The strings are also used for the JACK port names. It has been proposed in one of the comments in the PR to also show these technical names in the dialog. Previously they have not been translated (see line 174 in the original code before this PR) and I am not sure if they should be translated due to their rather technical nature.

An anonymous namespace can be nested within other namespaces such as the lmms namespace, just as an FYI

michaelgregorius · 2025-08-06T19:00:43Z

And it appears the PR title and description are inaccurate, and the screenshot out-of-date? Because there are input selection combo boxes too.

Yes, the screenshot is out of date due to the evolution that can be followed through the PR's comments. It should look somewhat like in this comment: #7919 (comment).

Do other people keep their original PR descriptions up-to-date with regards to all latter changes?

messmerd · 2025-08-06T21:21:32Z

Do other people keep their original PR descriptions up-to-date with regards to all latter changes?

Yes, otherwise it's misleading to people trying to understand what the PR does. (Like me as I'm writing July's progress report)

I ended up looking though the code changes to find out what this PR did because I couldn't trust the description and I didn't feel like reading though the whole conversation under the PR.

Also, GitHub saves edits to the PR description and comments, so anyone who wants to see the initial state of the PR for whatever reason can do so that way.

michaelgregorius · 2025-08-06T21:34:19Z

Do other people keep their original PR descriptions up-to-date with regards to all latter changes?

Yes, otherwise it's misleading to people trying to understand what the PR does. (Like me as I'm writing July's progress report)

I ended up looking though the code changes to find out what this PR did because I couldn't trust the description and I didn't feel like reading though the whole conversation under the PR.

I have now adjusted the PR's description according to the current state.

Thanks for doing the progress reports by the way! I find them very valuable and it's great that they are still done regularly!

michaelgregorius added 9 commits May 31, 2025 15:17

Init combo boxes with current input/output

67a17c7

When populating the combo boxes select the current input/output as saved in the configuration.

Remove handleRegistrationEvent

0aa3d31

Remove `AudioJack::handleRegistrationEvent` as it was only used for debugging so far.

Replace repeated hard-coded strings

a886aa3

Replace repeated hard-coded strings with references to static constant variables in the anonymous namespace. This should prevent subtle mistakes when working with the configuration values of the Jack driver.

Fix whitespace

e8f9bdc

michaelgregorius changed the title ~~Input output combo boxes for jack driver~~ Output combo boxes for Jack driver May 31, 2025

michaelgregorius linked an issue May 31, 2025 that may be closed by this pull request

Let users select Jack outputs from combo box #7918

Closed

michaelgregorius mentioned this pull request May 31, 2025

Sample Track Recording with Jack backend #7567

Merged

Introduce input selection

aa5311c

Introduce input selection for the Jack driver similar to how it is done for the outputs, i.e. saving to configuration, reconnection at driver start, etc.

michaelgregorius requested a review from JohannesLorenz May 31, 2025 17:03

michaelgregorius mentioned this pull request May 31, 2025

Input selection for Jack driver #7920

Closed

JohannesLorenz reviewed Jun 6, 2025

View reviewed changes

include/AudioJack.h Outdated Show resolved Hide resolved

src/core/audio/AudioJack.cpp Outdated Show resolved Hide resolved

michaelgregorius added 6 commits June 14, 2025 16:52

Let the tool buttons use available space

cc6b87b

Let the tool buttons stretch so that they look uniform and use all the available space.

Remove debug output

cd3fa37

Remove the printing of the audio port names in `getAudioPortNames`.

Switch back to InstantPopup

420acb2

Switch the popup mode of the tool buttons from `MenuButtonPopup` back to `InstantPopup` so that users can click everywhere. This works better now because the buttons use all the space and the little triangle can be seen better.

Make buildMenu static

6e1e462

Remove unnecessary whitespace

0a0054a

Make CodeFactor happy.

JohannesLorenz approved these changes Jun 19, 2025

View reviewed changes

src/core/audio/AudioJack.cpp Show resolved Hide resolved

bratpeki self-requested a review July 5, 2025 11:36

michaelgregorius added 3 commits July 9, 2025 16:29

Output messages only in debug builds

b04ff1b

Output the success/failure messages with regard to the reconnects only in debug builds.

bratpeki approved these changes Jul 16, 2025

View reviewed changes

michaelgregorius merged commit 997764a into LMMS:master Jul 16, 2025
11 checks passed

michaelgregorius deleted the InputOutputComboBoxesForJackDriver branch July 16, 2025 20:32

michaelgregorius mentioned this pull request Aug 3, 2025

Fix a segfault if JACK libs are missing #8026

Merged

messmerd reviewed Aug 6, 2025

View reviewed changes

michaelgregorius mentioned this pull request Aug 6, 2025

Fix memory problems #8032

Merged

AW1534 mentioned this pull request Oct 28, 2025

LMMS kicks out connected headphones when going to settings #8112

Open

1 task

Uh oh!

Output combo boxes for Jack driver #7919

Output combo boxes for Jack driver #7919

Uh oh!

Conversation

michaelgregorius commented May 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JohannesLorenz commented Jun 3, 2025

Uh oh!

michaelgregorius commented Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Potential fixes for the Setup Dialog

Uh oh!

JohannesLorenz commented Jun 6, 2025

Potential fixes for the Setup Dialog

Uh oh!

JohannesLorenz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

michaelgregorius commented Jun 14, 2025

Uh oh!

michaelgregorius commented Jun 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JohannesLorenz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bratpeki commented Jun 24, 2025

Uh oh!

bratpeki commented Jun 24, 2025

Uh oh!

michaelgregorius commented Jun 24, 2025

Uh oh!

bratpeki commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

messmerd commented Jun 24, 2025

Uh oh!

michaelgregorius commented Jun 27, 2025

Uh oh!

bratpeki commented Jul 9, 2025

Uh oh!

bratpeki commented Jul 9, 2025

Uh oh!

michaelgregorius commented Jul 9, 2025

Uh oh!

bratpeki commented Jul 10, 2025

Uh oh!

bratpeki left a comment

Choose a reason for hiding this comment

Uh oh!

michaelgregorius commented Jul 16, 2025

Uh oh!

Uh oh!

AW1534 commented Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

AW1534 commented Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

michaelgregorius commented Aug 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

michaelgregorius commented Aug 3, 2025

Uh oh!

michaelgregorius commented Aug 6, 2025

Uh oh!

messmerd left a comment

Choose a reason for hiding this comment

Uh oh!

messmerd Aug 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

michaelgregorius commented May 31, 2025 •

edited

Loading

michaelgregorius commented Jun 6, 2025 •

edited

Loading

michaelgregorius commented Jun 14, 2025 •

edited

Loading

bratpeki commented Jun 24, 2025 •

edited

Loading

AW1534 commented Aug 2, 2025 •

edited

Loading

AW1534 commented Aug 2, 2025 •

edited

Loading

michaelgregorius commented Aug 2, 2025 •

edited

Loading

messmerd Aug 6, 2025 •

edited

Loading

messmerd commented Aug 6, 2025 •

edited

Loading