protux-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Protux-devel] Bugs?


From: Luciano Giordana
Subject: Re: [Protux-devel] Bugs?
Date: Tue, 1 Jul 2003 18:43:35 -0400
User-agent: KMail/1.5

On Tuesday 01 July 2003 05:28 pm, Remon Sijrier wrote:
> Op woensdag 2 juli 2003 00:11, schreef Luciano Giordana:
> > Did you remove the  peak manually ?
>
> yes I removed it by hand, but this worked before. After removing the
> peakfile by hand, it was recreated. (Hm, still not getting why it shouldn't
> work, it worked before?! and peak.cc is regenarating the peakfile if it

.. if you RESTART protux, not DURING its usage...  which situation are you 
referring to ?


> doesn't exist) (Ehm, after reading this twice, I think I get it. :), it is
> actually the same problem as with the "drag and drop" bug, 2 processes try
> to read/write to/on the same object/variable, which sometimes results in a
> segfault, or a wrong value.)


>
> > protux is not prepared to handle this situation, that's why it is
> > crashing.
> >
> > If you want a good  challenge, you could try to make peak generation run
> > in a separated thread. Like in Vegas. If any class->recreate detects that
> > there is no peak for a given Audio, it will show
> >
> > BUILDING PEAKS , in the clips;
> >
> > mean while, a thread starts to generate (or regenerate) the peaks.
> >
> > When the peaks are available (you can create a boolean flag for it),
> > recreate is called to redraw the peaks.
> >
> > I suggest that you let it for later. By now, you can only detect if peak
> > is available, and in case it is not, show something like. "PEAKS NOT
> > AVAILABLE" on the clips..
> >
> >
> > Dont add this to BUGLIST or on savannah, since it always crashed in such
> > situation. It is a matter of improvement, not bug.
>
> Oke, but I already added it to BUGLIST :(, removed it also. But it is
> indeed not a bug.
>
> Thanks,
>
> Remon
>
> P.S. A bit offtopic, but the audio streams are directly written/read
> to/from the hard disk. Is there a plan to make some kind of
> "diskStream/audioStream" class which take's care of the reading/writing of
> the Streams to the hard disk. This has the benefit of making it possible to
> do things (peakbuilding) on the fly and gives much improvment on disk I/O ?
> Just an idea :)
>
> > On Tuesday 01 July 2003 04:55 pm, Remon Sijrier wrote:
> > > Another bug, should I post bugs on savannah or add it to BUGLIST ??
> > > Regarding to another mail, it should be set it the BUGLIST?
> > >
> > >
> > > I'll post it here, as you may have a clue wy this segfauls happens:
> > >
> > > One of your last changes (5 days ago) involved a change in
> > > Song::recreate. before this was called:
> > >   parentProject->get_bus_monitor()->clear();
> > >   after:
> > >           parentProject->get_bus_monitor()->refresh(); ,
> > >
> > > this due the much changed BusMonitor class?
> > >
> > > If I remove a peakfile, and start protux, somewhere in the process
> > > Song::recreate is called, then
> > > parentProject->get_bus_monitor()->refresh();
> > > which call's:
> > > if(!assocInterface->get_current_project()->get_current_song()->get_mixe
> > >r( )-
> > >
> > >>valid_playback_bus(b))
> > >
> > > get_current_song in Project.cc then segfaults.
> > >
> > > Normally, the peakfiles are (re)generated and protux continues
> > > starting.
> > >
> > > Remon
> > >
> > > P.S. Added it to the BUGLIST, number assigning?? Suggestions are
> > > welcome.
> > >
> > >
> > > _______________________________________________
> > > Protux-devel mailing list
> > > address@hidden
> > > http://mail.nongnu.org/mailman/listinfo/protux-devel
>
> _______________________________________________
> Protux-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/protux-devel

-- 
Best Regards
--
Luciano Giordana - Musician - Certified Java/GNU C++ Developer - Free Software 
Evangelist
Project Mustux - http://www.freesoftware.fsf.org/mustux
-- GNU/Linux adoption grew 65% only this yer. Smile : we're winning. --




reply via email to

[Prev in Thread] Current Thread [Next in Thread]