-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nsm seems to get a announce from two processes #131
Comments
Maybe NSM-Proxy comes close. I think it kills its own GUI (process) by SIGTERM. |
I believe I have duplicated the issue. When I set up a session in Agordejo,
I see a non-working qseq66 entry and a working seq66 entry. Not sure what is
up. I also found some minor lapses in configure.ac that I am fixing as well.
Thanks for the report!
|
I've been testing against old code (version 0.99.7 works properly) using nsm-legacy-gui because it outputs messages to the console. 0.99.16 starts qseq66, which then seems to spawn "seq66". If I stop qseq66, it stops both entries. If I start qseq66 again, another instance of seq66 is added to the client list. Still struggling with this one. |
I think I've got it fixed (in "wip" branch). Need to test a little more and do some cleanup. Then I will do your pull request. Fingers crossed, resting for now. The code change between 0.99.10 and 0.99.11 caused the issue. That was long ago; that'll teach me not to test NSM handling. :-( |
Fixes for NSM (session manager), build-file updates, and better PPQN and recording handling. A lot of little issues found and fixed, too. - Fixed issue #128 with expanded recording not working. The expansion is now continual, not waiting for a MIDI key to be struck. - Merged a fix from a pull request (issue #130) to update the "*.desktop" files. - Fixed issue #131 re faulty NSM interactions introduced in version 0.99.11, plus other related issues: - NSM (agordejo or nsm-legacy-gui) would show two clients: "qseq66" and "seq66" when adding only the "qseq66" client. - Saving via a remote NSM Save command or by the File / Save menu would not clear the modified flag. - Closing the session would not remove any external editor windows. - The main window now reflects the current record-loop style and new-pattern option as read from the 'usr' file. - Fixed the pattern editor so it reflects buss and channel settings made from the grid slot popup menu. - Fixed the display of tunes with various PPQNs such as 120 in the pattern editor. - Fixed zero-length notes caused by quantized recording. - Some automation actions need to work whether the action is "on" or "toggle". Fixed these 'ctrl' actions: - Save session (under NSM) or the MIDI file. - Record style select. - Quit. - Added "Clear events" to the grid slot popup menu. - Enhancements to pattern-editor note copy/paste. - Added 120 PPQN to the list of supported PPQNs. - Fixed File / New plus File Save overwriting the previous loaded file. - The main window now reflects the current record-loop style and new-pattern option as read from the 'usr' file. But note: - Renamed [new-pattern-editor] to [pattern-editor] in the 'usr' file. - The Quantized Record button in the pattern editor steps through None, Tighten, Quantize, Notemap, None.... Prettied-up the icons, too. - Added CONFIG\_DIR\_NAME and cleaned up configure.ac. This macro differentiates between client name and config directory name. Updated the Makefile sources. Do "./bootstrap --full-clean". - Updated the PDF documentation re the Import/Export functionality etc. - Upgraded the color palette code. - See NEWS and ChangeLog for full details.
I've added a pull request for the desktop file with NSM keys, but before you merge it, please check first if qseq66 is actually working in NSM, otherwise it would be better to leave it out for the time being.
It looks like it announces with two processes to the NSM daemon or something. Currently I don't have the time myself to test it further and to do follow up testing, sorry.
edit:
This is one added qseq66 client.
If this is by design, then it's the only NSM client I know of, that is doing it this way. If it can't be avoided, it might be better if the main qseq66 process is owning the other started process and kills it when the main process gets a
SIGTERM
signal from the NSM daemon and don't let that second process announce to the NSM daemon. But I don't know the details of how seq66 is doing this. Ideally the NSM daemon is the 'owner' of all the processes it starts and it just started one process here.The text was updated successfully, but these errors were encountered: