Rename "Song Editor" to "Sequencer"

[unfa]

The titles says it all.
Let's have shorter and more universal names,

[tresf]

👍

[diizy]

I like this idea.

[zonkmachine]

I think Song Editor better describes what it does.

[unfa]

Please elaborate.

I've wrote it before and I'll do it again, even better:

Not every track is a song, however, every sequence can be a song, or not.
What we use this for is arranging sequences of musical information to
create whatever we need.
I sometimes use LMMS for designing sound effects like this:
http://www.freesound.org/people/unfa/sounds/187119/
This project is not what I consider a song, but falls into an arrangement,
or a sequence if you please.

I think that "Sequence" is much more universal than "Song". It's a common
think in LMMS that some elements of it are named in a way that limits the
apparent usage.

It's not just "Song Editor" it's much more!
The same applies to the "Beat + Bassline Editor" - who says I can't put a
vocal sequence there? I did, because I wanted to arrange a few samples in a
pattern, or sequence, and re-use it.

Maybe "Song Editor" could be named "Arrangement" and "B+B Editor" could be
named "Sequences", but I think that

"Sequencer" + "Pattern Editor" (or even shorter: "Patterns" - as in
"Project Notes") look and sound good, and a bit better describing what
these UI elements do.

2014/1/24 Oskar Wallgren [email protected]

I think Song Editor better describes what it does.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/121#issuecomment-33185400
.

Tobiasz unfa

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$
!N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv
b+>+++ DI>+ D+ G e h-->- !r y--()
------END GEEK CODE BLOCK------

[zonkmachine]

Maybe your right, but equencer I associate with hardware sequencers and something that controls your synths and sounds. Control messages. When you add an actual audiotrack on top of the sequences as you can in LMMS, then sequencer isn't as fitting. 'Project Editor' maybe?

[unfa]

I guess we can look at some other establihsed software and find out what
they've come up with.

2014/1/24 Oskar Wallgren [email protected]

Maybe your right, but equencer I associate with hardware sequencers and
something that controls your synths and sounds. Control messages. When you
add an actual audiotrack on top of the sequences as you can in LMMS, then
sequencer isn't as fitting. 'Project Editor' maybe?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/121#issuecomment-33189440
.

Tobiasz unfa

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$
!N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv
b+>+++ DI>+ D+ G e h-->- !r y--()
------END GEEK CODE BLOCK------

[tresf]

LMMS is (by deffiniton) a software sequencer, right?

I can't think if a more appropriate word in this case, although I don't have the hardware "sequencing" history/experience to influence my understanding.

[pgiblock]

Project Editor (song), Pattern Editor (bb), Automation Editor, Piano Roll Editor. Possibly drop the "Editor" for the window titles. All of the above are technically "sequencers" in my opion. The big concept to illustrate is at what depth in the project hierarchy do they operate. And the song editor is the root.

[badosu]

Is this still a thing? If so, could someone point out how this change would affect LMMS holistically? I guess this would not just be a change to the window label but a fundamental terminology change.

[tresf]

Is this still a thing?

Yeah, it's still under (dormant) discussion. Most of the devs agreed for better names and this topic still remains relevant. :)

[badosu]

Oh, just noticed that this discussion is elaborated at #120. I'll check there.

[tresf]

Yeah, the rename issues should probably be organized and consolidated since nomanclature in general tends to affect a lot of the code, and influence one another.

[tresf]

I'd like to resurrect this thread. Most were in favor of changing it back in January 2014 when it was originally proposed. This is a large refactoring task.

[Wallacoloo]

@tresf Can this be as simple as a translation file edit? (I believe we can have an english translation file)

[tresf]

Can this be as simple as a translation file edit

Well, it could... We could make the class called _tmp too I suppose... 😃

[Wallacoloo]

@tresf Point taken - translation files might not be the best way to tackle this - indeed, I can think of multiple reasons why they aren't currently suited for the job.

We should come at it from an angle where it's easy to rename it again in the future though, right? I mean, it's pretty much impossible to make all of the sources trivially renamable, but from the UI perspective, it should amount to a single string constant being changed - right?

[tresf]

but from the UI perspective, it should amount to a single string constant being changed

I think this is one of those all-or-nothing scenarios where we just need to pick a new permanent name (or alternatively decide to keep what we have).

I don't think we'll ever have easy class renaming. :) From a UI perspective, you're right, the front end could be changed without changing the underlying class names, but I just think it would be harder for developers to discuss and would make the codebase confusing if they didn't match... at least in english.

[Wallacoloo]

@tresf hmm. I haven't dug into the code too far yet, but if we were to reduce this to one string constant per editor, I would suspect it allows for more code reuse.

For example, we could add a virtual method, editorName() to the Editor class & implement that in all the subclasses. Then the Editor class can be responsible for setting the Window title instead of implementing that functionality in every subclass, we can create the show/hide xxx options in the view menu programatically - for (editor : editors) menu->addAction(tr ("Show/Hide {1}").arg(editor->name()) ... I'm sure there are more areas that would benefit which I cannot yet think of.

[tresf]

As part of a pruning effort, this enhancement request is archived into a dedicated "Better Workflow" checklist here #4877.