seq66
seq66 copied to clipboard
ahlstromcj
NSM: seq66 in a new session should provide a blank project
Actually, the MIDI file is not being imported. What's happening is that the existing configuration in ~/.config/seq66/qseq66.rc is being copied to the new NSM session directory, and then Seq66 uses that to open the MIDI file from its fully-qualified path name. The workaround is to ignore the loaded file (confusing) or to first edit the existing "home" configuration to not load the files.
As far as a fix, one idea is to extract the path name from the most-recent filename, see if it matches the path ~/NSM Sessions/MyNewSession/seq66.nWFEW/midi, and only open the file if that is the case.
Another option is to prompt the user to accept or reject this file loading and opening, and perhaps an actual import of this file.
May need a way to detect a new NSM session.
Any other ideas?
Thanks for the report!
Don't assume ~/NSM Sessions. This can be changed by command line parameter --session-root .
Is the configuration really depended on the session? Normally all programs, even in NSM, have their own global config file in ~/.config/... with data like window positions, size, recently used files etc. That is not something that belongs in the session.
I also advice against any prompting. This should be solved automatically.
I am not sure what you mean "detect a new NSM session"? You, as the client, already knows if you are in an NSM session or not, after doing the initial session handshake. Everything after this point is up to the client. You can check if files below that path. see https://linuxaudio.github.io/new-session-manager/api/index.html#server-to-client-control-messages-open
Not to worry. Seq66 queries NSM for the session settings as per the documented protocol. My mention of "NSM Sessions" was purely an example for brevity. These session settings are shown (read-only) in the Session tab. As for configuration, Seq66 running normally offers command line selection of configuration files and the configuration directory, just in case the user has multiple types of setups. NSM makes this easier because the selection is automatic... just use the session's "config" directory. We want to handle cases where the user wants a different color palette, a different collection of ports and instruments, perhaps different 'ctrl' files, 'mutes'. The user could always replace the files with soft links to the global configuration files.
Thanks for the advice about not prompting. Simplifies things.
Finally, I had a brain fart about detecting a new NSM session. That's already in the code via a check to see if the NSM configuration directory (e.g. ~/NSM Sessions/seq66.nXYZZ/config) already has files. If not, it's a new session directory.
Frankly, I would follow the original API. Which is here: http://non.tuxfamily.org/nsm/API.html Session management should be simple, the original API is simple as it can be here with a reason. ~/NSM Sessions is the root folder. Keep it simple stupid.
Frankly, I would follow the original API. Which is here: http://non.tuxfamily.org/nsm/API.html Session management should be simple, the original API is simple as it can be here with a reason. ~/NSM Sessions is the root folder. Keep it simple stupid.
@grammoboy2 don't drag your crusades in here as well.
The NON session manager was and is abandoned. The last release was 2017 and now it is in fact abandoned: The author removed all code and bug reports from the internet. Distribution adoption also clearly favours New Session Manager.
It also is a sign that I am the one responding here, and not the NON author.
Latest Non-Daw release was last week. Not changing a API is a good thing. The last thing you want is a regular 'release pact' to make changes because of changes. The source code is available, just not on github for social and time management reasons.
Also for the GUI, most NSM users are just happy with it. It does what it does and does it well. If people wants a different GUI, they can make it obviously.
The source code is available
This is false.
Both github https://github.com/original-male/non/ and the original repo https://git.tuxfamily.org/non/non.git/
the mailing list is gone too.
Please stop telling plain lies. The Non session manager was and is abandoned... in your dreams. This is newspeak. You forked it, it's just for you own interest to say it's abandoned. You or you fans have not to power to abandoned the original project. It's ridiculous you think you can. It's show how wrong your way of forking is. It's not just forking anymore.
The source code is temporarily removed as well as the mailinglist. To take some time off to recover from this: http://non.tuxfamily.org/wiki/News
the code is not available right now, "later" can come at any point. we would appreciate the lies to stop too. getting really ridiculous at this point. @diovudau calling NSM abandoned is a bit much, but tbf to others here it was the impression we got since the author rage-quit and deleted everything but the website.
details and history here https://lists.linuxaudio.org/archives/linux-audio-dev/2021-February/037954.html Note how the NON "news" has no citations or links whatsoever...
to @ahlstromcj I am sorry about all this.
It's sad to see a group of people thinks they own linuxaudio.org and use their roles to take over a project. The same group is stopping a discussion on LAD. What has become of linuxaudio? A totalitarian state? Fork it fine, put it on your own website. But please keep the spirit of Free Software alive. Linuxaudio is not a totalitarian state. Thank you.
hmm who do you think actively maintains the linuxaudio servers? that keeps projects like a2jmidid, jack and others alive? this is not a conspiracy, other people simply did/do not step up to take up the work required to keep things running. so the people "in charge" happens to be usually the same ones, because no one else cares enough... :(
Jonathan himself phrased this whole situation very well many years ago https://lists.linuxaudio.org/archives/linux-audio-dev/2013-September/034141.html I recommend you to read that carefully and reflect.
Right now Seq66 is going to follow the original protocol, barring mistakes or ambiguities on my part. Frankly, I am rushing to get through most of the bugs I've found while writing a user's manual so that I can finally have a chance to actual use Seq66 as opposed to testing it. :-D As far as forks go, I'm fine with them. Ferment is good!
Right now Seq66 is going to follow the original protocol, barring mistakes or ambiguities on my part.
Do that. For a client-developer it does not matter which document you read. The client/server API is the same and 100% compatible.
Going to close this one. If you really want an empty session, first hide any existing qseq66*.* files so that qseq66 running in an NSM session will create the configuration files from scratch. Or edit thw normal qseq66*.* files to suit any new NSM session you wish to create; then creating the new session will recreate the existing files in the NSM session.
But then seq66's start behaviour will continue to be confusing.
I'm a bit confused, isn't this fairly trivial? Just check if under NSM, check the session directory, if no configuration for that instance is detected then generate a blank set? Or am I missing something?
There's nothing in the NSM specification that says you cannot import an existing configuration. Seq66 under NSM checks if there is already an NSM configuration. If not, it then tries to copy the configuration from /home/user/.config/seq66. The reason for this is the following scenario:
I create a large set of MIDI files, and work them up into a set of playlists. I do this before I discover NSM. Now I want to run under NSM and still have my playlists and MIDI files. Seq66 detects this and replicates the whole thing, MIDI files and all, in that NSM session.
Then I can hide or remove the regular configuration.
The next NSM session I create will be clean.
So if you want a clean configuration, either have a clean configuration in /home/user/.config/seq66, or remove it.
I consider this behavior a feature, not a bug, and if it isn't already documented in the "Session" section of the user manual, I will make sure it is documented.
Having said all that, it is probably good to disable the "load-most-recent" option when first running in a new session.
-------- Milkii Brewster 17:11 Fri 07 Jan --------
But then seq66's start behaviour will continue to be confusing.
I'm a bit confused, isn't this fairly trivial? Just check if under NSM, check the session directory, if no configuration for that instance is detected then generate a blank set? Or am I missing something?
-- Reply to this email directly or view it on GitHub: https://github.com/ahlstromcj/seq66/issues/40#issuecomment-1007852995 You are receiving this because you modified the open/close state.
Message ID: @.***>
-- You shall be rewarded for a dastardly deed.
Hmmm, I could offload this initial setup import into the File / Import Into Session command. Currently that only imports a MIDI file, not a whole project configuration. I'll re-open it for now.
Why not just have an import project menu feature?
To my perspective, the user expectation that starting a session from scratch will start a session from scratch is natural.
Plus, I can't imagine the ratio of situations for a single user transitioning from a non-NSM seq66 project to one under NSM will be higher than creating a project under NSM from scratch. If one is consistently using session management, then the then one is going to start new projects from the point of already being under season management.
And cloning a project is already dealt with at the NSM front-end gui.
Edit: missed the previous comment
I also see that there is a "New MIDI File", but the NSM API also allows for a new project. However API.mu's description of "New" leaves a lot of room for interpretation, in my view.
It also occurs to me that some users may want a stock initial configuration that serves as a template for the creation of new NSM session.
In any case, I will first have to make sure the automatic project import already done is encapsulated in a single function call. At that point it would be easy to modify the Import option. Same for the New session option.
Sigh. It never ends.
Working on it in the 0_98_0 branch. Got rid of the automatic import under NSM, and there's now a menu entry to import a project. Also need an import-playlist command, thinking that one through. Also rearranging the File menu since it is getting full.
-------- Milkii Brewster 05:21 Sat 08 Jan --------
Why not just have an import project menu feature?
Truly removed the automatic reading of the base configuration (~/.config/seq66/qseq66.rc) under NSM. Still working through making sure that the configuration saves correctly to the session directory, and rethinking the process for importing an existing base configuration. Other minor issues. Added code to detect immediately that the parent process is 'nsmd' to avoid reading the base configuration.
I think this works (in the portfix branch, which is essentially now my work-in-progress directory. Seq66 now no longer copies any configuration files when a new NSM session is created. The user must use File / Import Project Configuration and then use the NSM client GUI to stop and restart Seq66. (Outside a session, the restart is automatic). I also now hide the "X" button in the window title bar. Seq66 still responds to SIGTERM so that NSMD can stop it; the window manager will have other ways to send SIGTERM, but the lack of an "X" should reduce the chances of the user killing it. Anyway, still some more stuff to whack at, so I'll close this later.