The best solution to get correct time values when the tempo is automated is to
read the tempo at the cursor position from the automation track. It is also
interesting to update the tempo value shown in the GUI.
Some other problems can also be fixed if the user is not allowed to change the
tempo
I have seen no problems in the time value when "playing" the song with an
automated tempo. However, wrong values are shown when moving the cursor
manually.
> Date: Thu, 6 Feb 2014 20:32:52 +0100
> From: tobias.doerf...@gmail.com
> To: meta...@hotmail.com
> CC: lmms-devel@lists.sourceforge.net
>
This seems to be almost the definitive solution for most of the issues related
to the time display widget (at least in "min/sec/msec" mode).
Change the song::getMilliseconds() method to:
inline int getMilliseconds( PlayModes playMode ) const
{
return ( m_playPos[playMode].getTicks()*60*1000
Things can be simplified if the elapsed milliseconds are not stored in the
class, but always calculated by the song::getMilliseconds() method.
A way to calculate the elapsed milliseconds for different play modes (song,
beat/bassline, piano roll pattern, ...) is needed.
What about using the Space key for playing and pausing and a different key for
stopping? This would cause the Space key to correspond exactly to the
"Play/Pause" button.
> Date: Wed, 5 Feb 2014 23:51:42 +0100
> From: tobias.doerf...@gmail.com
> To: meta...@hotmail.com
> CC: lmms-devel@lists.sour
I think I have found at least the reason why the time widget continues to run
when a beat/bassline or piano roll pattern loops.
In the method song::processNextBuffer(), there is a line with the comment "//
end of played object reached?" followed by an "if" block. Nothing is done
inside this blo
The song class has a "setPlayPos" method, but the playing position is set
manually in some parts of the class. The elapsed milliseconds are also
calculated manually. Can anyone say why this method is not used?
-
It is perfectly possible to fix the time widget to work properly with the
beat/bassline editor and avoid adding more elements to the GUI, but there is
still a problem: the widget only changes its value to the time position of a
different editor when the user starts playing it or moves the positi
A "TimeDisplayWidget" class exists already.
If I understood well, you prefer each editor to have its own time display. Is
this correct?
> From: eagles051...@gmail.com
> To: lmms-devel@lists.sourceforge.net
> Date: Wed, 5 Feb 2014 15:47:01 +0100
> Subject: Re: [LMMS-devel] Time dis
All right, it is not in the song editor. My mistake.
I think about two possibilities:
Add one time display widget to each editorKeep the current widget, but change
the displayed time when the user selects a different editor
What do you think?
> From: eagles051...@gmail.com
> To: lmms-devel@lis
All right, it is not in the song editor. My mistake.
I think about two possibilities:
Add one time display widget to each editorKeep the current widget, but change
the displayed time when the user selects a different editor
What do you think?
> From: eagles051...@gmail.com
> To: lmms-devel@lis
t distinct though for each player?
>
> On Wednesday, February 05, 2014 12:10:03 PM Alexandre Almeida wrote:
> > I have already filed a number of issues related to this widget.
> >
> > What do you think about adding a distinct time display widget to each
> > editor
I have already filed a number of issues related to this widget.
What do you think about adding a distinct time display widget to each editor?
> From: eagles051...@gmail.com
> To: lmms-devel@lists.sourceforge.net
> Date: Wed, 5 Feb 2014 14:53:31 +0100
> Subject: Re: [LMMS-devel] Time display widge
I have already filed a number of issues related to this widget.
What do you think about adding a distinct time display widget to each editor?
> From: eagles051...@gmail.com
> To: lmms-devel@lists.sourceforge.net
> Date: Wed, 5 Feb 2014 14:53:31 +0100
> Subject: Re: [LMMS-devel] Time display widge
The time display widget (which I called "time marker" before looking at the
code and finding this name) is located in the song editor, but also displays
the time for beats/basslines and patterns on the piano roll (in the case of the
beats/basslines, the value is wrong). I think this makes no sen
I see no difference between "stop" with the option "After stopping keep
position" and "pause". Do you think this option can be removed?
--
Managing the Performance of Cloud-Based A
Maybe someone has already noticed, but there is another inconsistency: The song
editor has an "Edit mode", but the piano roll has a "Select mode", both using
the same icon. The edit mode in the song editor is the only one that can move a
selected block, but its supposed equivalent in the piano r
The "Play/Pause" button also has problems, which happen because the icon for
this button is updated before the status of the song is changed from "playing"
to "paused" and vice-versa. The same is true for a beat+bassline and piano roll
sequence.
Why was my patch to correct the problems with the play/pause button not applied
to this release?
From: unf...@gmail.com
Date: Wed, 1 May 2013 02:45:56 +0200
To: tobias.doerf...@gmail.com
CC: lmms-devel@lists.sourceforge.net; lmms-us...@lists.sourceforge.net
Subject: Re: [LMMS-devel] LMMS 0.4.14
Here are the patches which correct almost entirely the problems with the
"play/pause" button of the song editor.
The automation editor is the only editor which still has problems.
An issue I have noticed (not related to the "play/pause" button) is that the
Beat+Bassline Editor does not open if
I made some modifications in the sources of LMMS 0.4.13 to correct the problems
with the "play/pause" button of the song editor. An issue that can still be
seen is that the button is not always properly updated when one starts playing
the contents of a different editor (BB, for example).
A pos
It seems that the new version of the program forces the tempo to be 140 BPM
when the cursor goes back to the beginning of the song if loop-points are
enabled.
I also think that the default tempo should be 120, not 140 BPM.
Another thing: what happened to Unison?
If an editor is paused, long ZynAddSubFX notes continue playing.
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
Are you guys also having bugs in TripleOscillator's knobs?
The "lines" over the knobs are not drawn in the correct position and black
rectangles are drawn instead of some of the knobs.
--
Is there any new LMMS version planned to be released before Unison?
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challe
Why are m_exporting, m_recording, m_playing and m_paused volatile variables.
What can change these variables outside LMMS?
--
This SF.net email is sponsored by
Make an app they
Apparently, isPlaying() does not return the correct value.
I noticed this after doing a modification in the file "gui/song_editor.cpp"
(function "songEditor::play()"):
Original: if( m_s->playMode() == song::Mode_PlaySong )
My modification: if( m_s->isPlaying )
The "play" icon is shown when the
The "play/pause" button has some ploblems:
In the "Song-Editor":
1. If the song is playing and it is clicked, the song is paused, but its icon
does not change from "pause" (two bars) to "play" (triangle).
2. The song stops when opening the "Open file" dialog, but the icon of the
button does not
A feature that would be interesting is the ability to make a sequence once and
play it in different notes, as a chord or an arpeggio.
_
Fique protegido de ameças utilizando o Novo Internet E
After the window of the program is closed, its process continues running.
Is that a bug?
_
Você já ama o Messenger? Conheça ainda mais sobre ele no Novo site de Windows
Live.
http://www.wind
A feature LMMS lacks is the ability to move istruments from one position to
another in the "Song-Editor" and in the "Beat+Bassline Editor".
I think this feature should be added.
_
Acesse o
31 matches
Mail list logo
