I have checked in a fix for the threading bug in the default build which Dominic pointed out. I have tested the new fix and can report that it fixes a tendency for the playhead to freeze during playback. I propose that this version should now be tested for release. Only the non-jack version is targetted by this release, as fixing problems in the jack version is going to take more work. Any comments on this proposal will be most welcome. Richard
Hi Richard, On Saturday 09 June 2012 15:30:20 Richard Shann wrote: > I have checked in a fix for the threading bug in the default build > which Dominic pointed out. I have tested the new fix and can report > that it fixes a tendency for the playhead to freeze during playback. My first attempt to fix this issue was pretty much identical to the change you committed. It fixed the most obvious threading/realtime problems, but I still see some weird glitches with score/playhead drawing that weren't there before. Is there a reason to trigger page_viewport() directly from the event queue code (and potentially multiple times, once for each event)? Why not do this somewhere in queue_thread_func(), like all other GUI updates during playback? Dominic
On Fri, 2012-06-15 at 03:54 +0200, Dominic Sacré wrote: > Hi Richard, > > On Saturday 09 June 2012 15:30:20 Richard Shann wrote: > > I have checked in a fix for the threading bug in the default build > > which Dominic pointed out. I have tested the new fix and can report > > that it fixes a tendency for the playhead to freeze during playback. > > My first attempt to fix this issue was pretty much identical to the change > you committed. It fixed the most obvious threading/realtime problems, but > I still see some weird glitches with score/playhead drawing that weren't > there before. > > Is there a reason to trigger page_viewport() directly from the event queue > code (and potentially multiple times, once for each event)? Why not do > this somewhere in queue_thread_func(), like all other GUI updates during > playback? Sorry to be so long replying - partly because I am so unfamiliar with the code (my memory being rather short-term ...) that I don't know the answer. I didn't ever really get to grips with "what is happening when" in this code - I started off analysing it following the alsa backend code only to find that the portaudio backend works rather differently - portaudio (IIRC) providing interrupts (or possibly it is just another thread, not explicitly started by us) which progress the time. I haven't seen any playhead glitches now, but I still heard the (horrendous) blurting out of everything (?) before Play From Cursor command. I put the ? there because I am not sure quite what is being emitted, but a lot of notes at once. Perhaps just what was buffered(Continue reading)
Jeremiah, I am now sitting on a significant chunk of Denemo code which much improves the program. Will it hinder you in releasing 0.9.4 if I check this into master now? AFAIK the current master is good for release (though Dominic still sees some playback display glitches these are also present in the previous release, so they are not a regression). Richard
On Fri, 2012-06-15 at 03:54 +0200, Dominic Sacré wrote:
> Is there a reason to trigger page_viewport() directly from the event
> queue
> code (and potentially multiple times, once for each event)? Why not
> do
> this somewhere in queue_thread_func(), like all other GUI updates
> during
> playback?
I just experimented with this - I moved the call to be inside this loop
while ((event = get_smf_event(until_time))) {
write_event_to_queue(AUDIO_BACKEND, event);
write_event_to_queue(MIDI_BACKEND, event);
}
and the paging got much glitchier :(
Richard
_______________________________________________
Denemo-devel mailing list
Denemo-devel <at> gnu.org
https://lists.gnu.org/mailman/listinfo/denemo-devel
Ok. I will tar it up and put on denemo.org or do you want me to ftp to straight to savannah? Jeremiah Sent from my Samsung smartphone on AT&T Richard Shann <richard.shann@...> wrote: >Jeremiah, > >I am now sitting on a significant chunk of Denemo code which much >improves the program. Will it hinder you in releasing 0.9.4 if I check >this into master now? AFAIK the current master is good for release >(though Dominic still sees some playback display glitches these are also >present in the previous release, so they are not a regression). > >Richard > > > >_______________________________________________ >Denemo-devel mailing list >Denemo-devel@... >https://lists.gnu.org/mailman/listinfo/denemo-devel
It will need to be on denemo.org pointed to by the release-candidate link, so that we can check it is ok for all interested parties before uploading to savannah. Richard On Mon, 2012-06-18 at 13:25 -0500, Jeremiah Benham wrote: > Ok. I will tar it up and put on denemo.org or do you want me to ftp to straight to savannah? > > Jeremiah > > Sent from my Samsung smartphone on AT&T > > Richard Shann <richard.shann@...> wrote: > > >Jeremiah, > > > >I am now sitting on a significant chunk of Denemo code which much > >improves the program. Will it hinder you in releasing 0.9.4 if I check > >this into master now? AFAIK the current master is good for release > >(though Dominic still sees some playback display glitches these are also > >present in the previous release, so they are not a regression). > > > >Richard > > > > > > > >_______________________________________________ > >Denemo-devel mailing list > >Denemo-devel@... > >https://lists.gnu.org/mailman/listinfo/denemo-devel(Continue reading)
On 06/18/2012 02:20 PM, Richard Shann wrote: > It will need to be on denemo.org pointed to by the release-candidate > link, so that we can check it is ok for all interested parties before > uploading to savannah. Ok. Done. Jeremiah > Richard > > On Mon, 2012-06-18 at 13:25 -0500, Jeremiah Benham wrote: >> Ok. I will tar it up and put on denemo.org or do you want me to ftp to straight to savannah? >> >> Jeremiah >> >> Sent from my Samsung smartphone on AT&T >> >> Richard Shann<richard.shann@...> wrote: >> >>> Jeremiah, >>> >>> I am now sitting on a significant chunk of Denemo code which much >>> improves the program. Will it hinder you in releasing 0.9.4 if I check >>> this into master now? AFAIK the current master is good for release >>> (though Dominic still sees some playback display glitches these are also >>> present in the previous release, so they are not a regression). >>> >>> Richard >>> >>>(Continue reading)
I downloaded the release candidate and it built ok for me. I think we can release this. If you move master on to 0.9.5 I can commit my work on layout editing, and tooltips. Richard On Mon, 2012-06-18 at 15:44 -0500, Jeremiah Benham wrote: > On 06/18/2012 02:20 PM, Richard Shann wrote: > > It will need to be on denemo.org pointed to by the release-candidate > > link, so that we can check it is ok for all interested parties before > > uploading to savannah. > Ok. Done. > > Jeremiah > > > Richard > > > > On Mon, 2012-06-18 at 13:25 -0500, Jeremiah Benham wrote: > >> Ok. I will tar it up and put on denemo.org or do you want me to ftp to straight to savannah? > >> > >> Jeremiah > >> > >> Sent from my Samsung smartphone on AT&T > >> > >> Richard Shann<richard.shann@...> wrote: > >> > >>> Jeremiah, > >>> > >>> I am now sitting on a significant chunk of Denemo code which much > >>> improves the program. Will it hinder you in releasing 0.9.4 if I check(Continue reading)
RSS Feed