OD turned off in latest alpha?
|
|
Michael Chinen
|
It appears On-Demand loading is turned off by default in the latest
alpha. Is this because the ffmpeg importer was enabled? If so we need to discuss where we are heading. We were talking earlier about the possibility of making ffmpeg import OD compatible for possibly all file types. I have some questions about it. Does ffmpeg import allow for aliased wave files? The old import had two methods of loading wavs via copy or aliased. The cop-out or the in-the-meantime is to have ffmpeg import redirect (non GSM) wav files to the old importer. Michael ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Audacity-devel mailing list Audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
Gale Andrews
|
| From "Michael Chinen" <mchinen@...> | Tue, 1 Jul 2008 21:36:23 -0400 | Subject: [Audacity-devel] OD turned off in latest alpha? > It appears On-Demand loading is turned off by default in the latest > alpha. Is this because the ffmpeg importer was enabled? On-demand is on by default in Experimental.h which affects all platforms, and on-demand occurs for me as long as the filter in the import dialogue is not set to "FFmpeg-compatible files" (i.e. same behaviour as before). However as I mentioned on the Wiki I am quite concerned about how we "educate" people about load-on-demand. The solution with the progress bar embedded in the waveform seems to me to have two problems: a) Very short tracks under a minute long (here anyway) load on demand with a kind of subliminal green flash across the screen width that is very disconcerting until you know what it means. A similar "subliminal" dialogue box would not have this problem b) Very long files have the problem that the progress bar suggests (as progress bars usually do) that you must wait for completion. If users do this, the whole benefit of OD is lost. I suggested we might be able to have a background for the on-demand stripes that said something like "loading - click anywhere to play or edit". That may not even be feasible, but I do think we need to do something, or go back to a standard progress bar (or some kind of information box?) that explains what is happening, and which can be prevented from appearing again by a checkbox. > If so we need to discuss where we are heading. > > We were talking earlier about the possibility of making ffmpeg import > OD compatible for possibly all file types. > > I have some questions about it. > > Does ffmpeg import allow for aliased wave files? The old import had > two methods of loading wavs via copy or aliased. > > The cop-out or the in-the-meantime is to have ffmpeg import redirect > (non GSM) wav files to the old importer. I'd certainly hope that OD could work for as many file types as possible (presumably they have to be seekable?); and as I said before it's a considerable weakness that you can't leave the import filter set to "FFmepg-compatible files" and then "load on demand" a routine PCM WAV file. Gale ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Audacity-devel mailing list Audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
LRN
|
Gale Andrews wrote:
> | From "Michael Chinen"<mchinen@...> > | Tue, 1 Jul 2008 21:36:23 -0400 > | Subject: [Audacity-devel] OD turned off in latest alpha? > >> It appears On-Demand loading is turned off by default in the latest >> alpha. Is this because the ffmpeg importer was enabled? >> > > On-demand is on by default in Experimental.h which affects all platforms, > and on-demand occurs for me as long as the filter in the import dialogue > is not set to "FFmpeg-compatible files" (i.e. same behaviour as before). > > However as I mentioned on the Wiki I am quite concerned about how > we "educate" people about load-on-demand. The solution with the > progress bar embedded in the waveform seems to me to have two > problems: > > a) Very short tracks under a minute long (here anyway) load on demand > with a kind of subliminal green flash across the screen width that is > very disconcerting until you know what it means. A similar "subliminal" > dialogue box would not have this problem > > b) Very long files have the problem that the progress bar suggests (as > progress bars usually do) that you must wait for completion. If users do > this, the whole benefit of OD is lost. I suggested we might be able to > have a background for the on-demand stripes that said something like > "loading - click anywhere to play or edit". That may not even be > feasible, but I do think we need to do something, or go back to a > standard progress bar (or some kind of information box?) that explains > what is happening, and which can be prevented from appearing again > by a checkbox. > > a message like "File is being imported. You may wait until importing is complete or allow it to be imported in background (not all parts of audio will be accessible until the whole file is imported). And two buttons - "Import in background" and "Cancel". And the progress bar with <time passed> and <eta>. > > >> If so we need to discuss where we are heading. >> >> We were talking earlier about the possibility of making ffmpeg import >> OD compatible for possibly all file types. >> >> I have some questions about it. >> >> Does ffmpeg import allow for aliased wave files? The old import had >> two methods of loading wavs via copy or aliased. >> >> The cop-out or the in-the-meantime is to have ffmpeg import redirect >> (non GSM) wav files to the old importer. >> > > I'd certainly hope that OD could work for as many file types as > possible (presumably they have to be seekable?); and as I said before > it's a considerable weakness that you can't leave the import filter set > to "FFmepg-compatible files" and then "load on demand" a routine > PCM WAV file. > on-demand loading actually works and re-implement the same behaviour for FFmpeg importer. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Audacity-devel mailing list Audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
|
Michael Chinen
|
2008/7/2 Gale Andrews <gale@...>
> On-demand is on by default in Experimental.h which affects all platforms, > and on-demand occurs for me as long as the filter in the import dialogue > is not set to "FFmpeg-compatible files" (i.e. same behaviour as before). The CVS_HEAD has this behavior, but the 1.3.5d (and c yesterday) I got from leland today didn't use on-demand when loading wave files. > However as I mentioned on the Wiki I am quite concerned about how > we "educate" people about load-on-demand. The solution with the > progress bar embedded in the waveform seems to me to have two > problems: > > a) Very short tracks under a minute long (here anyway) load on demand > with a kind of subliminal green flash across the screen width that is > very disconcerting until you know what it means. A similar "subliminal" > dialogue box would not have this problem > > b) Very long files have the problem that the progress bar suggests (as > progress bars usually do) that you must wait for completion. If users do > this, the whole benefit of OD is lost. I suggested we might be able to > have a background for the on-demand stripes that said something like > "loading - click anywhere to play or edit". That may not even be > feasible, but I do think we need to do something, or go back to a > standard progress bar (or some kind of information box?) that explains > what is happening, and which can be prevented from appearing again > by a checkbox. click to..." idea. The reason it's called on-demand is because In the future once you click on a section it'll start loading from that point. So maybe something like "Loading Waveform Image - click to load immediately". That way the user might get the idea that it is just the image that is loading and they can play/edit it as normal while the OD loading is underway. > > >> If so we need to discuss where we are heading. >> >> We were talking earlier about the possibility of making ffmpeg import >> OD compatible for possibly all file types. >> >> I have some questions about it. >> >> Does ffmpeg import allow for aliased wave files? The old import had >> two methods of loading wavs via copy or aliased. >> >> The cop-out or the in-the-meantime is to have ffmpeg import redirect >> (non GSM) wav files to the old importer. > > I'd certainly hope that OD could work for as many file types as > possible (presumably they have to be seekable?); and as I said before > it's a considerable weakness that you can't leave the import filter set > to "FFmepg-compatible files" and then "load on demand" a routine > PCM WAV file. on-demandness will lessen and we will just get background loading with the user being able to immediately edit the parts that have been loaded. Those cases will be very different from the current OD tasks, since right now we have the real audio data in an aliased file from the start, so we know things like definite length, etc. Michael ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Audacity-devel mailing list Audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
|
Michael Chinen
|
2008/7/2 LRN <lrn1986@...>:
>> >> >>> If so we need to discuss where we are heading. >>> >>> We were talking earlier about the possibility of making ffmpeg import >>> OD compatible for possibly all file types. >>> >>> I have some questions about it. >>> >>> Does ffmpeg import allow for aliased wave files? The old import had >>> two methods of loading wavs via copy or aliased. >>> >>> The cop-out or the in-the-meantime is to have ffmpeg import redirect >>> (non GSM) wav files to the old importer. >>> >> >> I'd certainly hope that OD could work for as many file types as >> possible (presumably they have to be seekable?); and as I said before >> it's a considerable weakness that you can't leave the import filter set >> to "FFmepg-compatible files" and then "load on demand" a routine >> PCM WAV file. >> > Sorry, never took time to look at PCM importer to get the idea how this > on-demand loading actually works and re-implement the same behaviour for > FFmpeg importer. So about aliasing, when you import a PCM through ffmpeg is there support for PCMAliasBlockFiles? Or does it make copies of the data using SimpleBlockFile? If we could make a FFMpegAliasBlockFile that roughly corresponds to PCMAliasBlockFile then it would be pretty easy to integrate with OD. Michael ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Audacity-devel mailing list Audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
|
LRN
|
Michael Chinen wrote:
> 2008/7/2 LRN<lrn1986@...>: > >>> >>>> If so we need to discuss where we are heading. >>>> >>>> We were talking earlier about the possibility of making ffmpeg import >>>> OD compatible for possibly all file types. >>>> >>>> I have some questions about it. >>>> >>>> Does ffmpeg import allow for aliased wave files? The old import had >>>> two methods of loading wavs via copy or aliased. >>>> >>>> The cop-out or the in-the-meantime is to have ffmpeg import redirect >>>> (non GSM) wav files to the old importer. >>>> >>>> >>> I'd certainly hope that OD could work for as many file types as >>> possible (presumably they have to be seekable?); and as I said before >>> it's a considerable weakness that you can't leave the import filter set >>> to "FFmepg-compatible files" and then "load on demand" a routine >>> PCM WAV file. >>> >>> >> Sorry, never took time to look at PCM importer to get the idea how this >> on-demand loading actually works and re-implement the same behaviour for >> FFmpeg importer. >> > I've still yet to spend the time to delve in. > > So about aliasing, when you import a PCM through ffmpeg is there > support for PCMAliasBlockFiles? > Or does it make copies of the data > using SimpleBlockFile? FFmpeg importer, like all other importers (FLAC, MP3, Vorbis), creates a few WaveTrack objects (one object per channel) and feeds decoded data to Append() method of each object. Data usually comes interleaved, so each new chunk alloes us to feed all channels for one stream, and streams are usually inverleaved too, meaning that each new chunk feeds different stream (unless there's only one stream being imported). > If we could make a FFMpegAliasBlockFile that > roughly corresponds to PCMAliasBlockFile then it would be pretty easy > to integrate with OD. > Yeah, by looking at ImportPCM i realized that actual importing is done in ODPCMAliasBlockFile...As i said, i never touched PCMAliasBlockFile, because it is not used in any importers looked upon. Let's do it like this: look around the ImportFLAC (or any other non-PCM importer) and try to implement on-demand loading for this format. After that i would be easy for me to make the same thing for FFmpeg importer. Well, unless we're only planning to implement on-demand loading for uncompressed files. I think the root of the problem is that on-demand loading is designed to work with uncompressed audio only, and only when "edit" mode is enabled, so actual audio, as far as i understand, is loaded directly from the real files rather than from copies. But all non-libsndfile importers (including FFmpeg) always work in copy mode. Correct me if i am wrong. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Audacity-devel mailing list Audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
|
Michael Chinen
|
2008/7/2 LRN <lrn1986@...>:
> Let's do it like this: look around the ImportFLAC (or any other non-PCM > importer) and try to implement on-demand loading for this format. After > that i would be easy for me to make the same thing for FFmpeg importer. > Well, unless we're only planning to implement on-demand loading for > uncompressed files. Sounds good, I'll let you know how it goes. > > I think the root of the problem is that on-demand loading is designed to > work with uncompressed audio only, and only when "edit" mode is enabled, > so actual audio, as far as i understand, is loaded directly from the > real files rather than from copies. But all non-libsndfile importers > (including FFmpeg) always work in copy mode. > Correct me if i am wrong. Yes, it was designed that way to be as fast as possible. For compressed formats we will have to add more structures that make sense. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Audacity-devel mailing list Audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
Richard Ash (audacity-help)
|
On Wed, 2008-07-02 at 23:19 +0400, LRN wrote:
> Michael Chinen wrote: > >>>> We were talking earlier about the possibility of making ffmpeg import > >>>> OD compatible for possibly all file types. > >>>> Does ffmpeg import allow for aliased wave files? The old import had > >>>> two methods of loading wavs via copy or aliased. > >>>> The cop-out or the in-the-meantime is to have ffmpeg import redirect > >>>> (non GSM) wav files to the old importer. This is also necessary for any uncompressed file with deeper than 16-bit data in it, because ffmpeg doesn't have any support for bit depths other than 16-bit and some 8-bit support. > >>> I'd certainly hope that OD could work for as many file types as > >>> possible (presumably they have to be seekable?); and as I said before > >>> it's a considerable weakness that you can't leave the import filter set > >>> to "FFmepg-compatible files" and then "load on demand" a routine > >>> PCM WAV file. This is why I sent the extended email soon after the importer was set up like this outlining a structure that would automatically choose the correct "best" importer for a file. One of the side effects of this was the decision could take account of whether a particular file was seekable, whether the length was known from the header and various other things. > >> Sorry, never took time to look at PCM importer to get the idea how this > >> on-demand loading actually works and re-implement the same behaviour for > >> FFmpeg importer. > >> > > I've still yet to spend the time to delve in. > > > > So about aliasing, when you import a PCM through ffmpeg is there > > support for PCMAliasBlockFiles? > Never heard of such thing. > > Or does it make copies of the data > > using SimpleBlockFile? > FFmpeg importer, like all other importers (FLAC, MP3, Vorbis), creates a > few WaveTrack objects (one object per channel) and feeds decoded data to > Append() method of each object. The PCM importer using libsndfile operates at an unusually low level, because it generates block files directly. > Let's do it like this: look around the ImportFLAC (or any other non-PCM > importer) and try to implement on-demand loading for this format. After > that i would be easy for me to make the same thing for FFmpeg importer. > Well, unless we're only planning to implement on-demand loading for > uncompressed files. > I think the root of the problem is that on-demand loading is designed to > work with uncompressed audio only, and only when "edit" mode is enabled, > so actual audio, as far as i understand, is loaded directly from the > real files rather than from copies. But all non-libsndfile importers > (including FFmpeg) always work in copy mode. On demand loading of some file types is never going to be a practical idea to implement, because of the way they are structured. The main requirement for on-demand to be feasible is that retrieving an arbitrary time range of uncompressed samples from the file has to be an efficient operation. For uncompressed files, this is always the case, because the bit rate is constant, and so the byte position of any given sample can be calculated from the time and the bite rate. Seeking is therefore easy because it can use fseek(), and decoding can start from any sample because each sample is independent of it's neighbours. This means reading data when it needed is a quick operation, and we don't have to do any reading in order to create the track outline minus the waveform data (know the length, channels etc). At the other end, consider a VBR MP3 file. It doesn't have any headers, so the length isn't known at the start of the read process. Because it's a VBR encoding, we can't predict where any given sample will come from externally. The format doesn't have any sort of seek table, so we can't find the right encoding block that way either. So the best approximation we can make is to read each block start, then skip the block if it isn't the one we want. This is of course a slow process. If we work round this, for example by scanning the file and building a seek table, then we find another problem. Because the encoding is block based, we have to start decoding before the sample we want, in order to start at a block boundary in the MP3 data. We will also have to keep decoding at the end beyond the end of the wanted data to clear the last block. This makes the reader both more complex and less efficient than an in-order reader. The effect of this is that to know the length of an MP3 file you have to read all of it. To seek out an arbitrary section of the file you have to read all of the file from the start of the file to the bit you want, then do a messy, slow decode process. So for the same reason that a "read from original file" option doesn't make much sense for MP3 files, nor does a read-on-demand option. For other, more advanced, formats the distinction is less clear. A raw FLAC file is always VBR, and a seek table is optional. Decoding a FLAC file has to happen in blocks, but it relatively cheap (on most systems, decode is a disk-bound operation not CPU-bound). So if the seek table exists in a file, both "read as from file" and "load on demand" can be done reasonably effectively and will be useful. If the seek table isn't there, then to create it will mean reading the whole of the file to build it. In that circumstance it makes more sense to read the file once and deliver it into the audacity project at that point rather than read it all twice, once to build the TOC (which has to happen for the track to load) and again to get the data. Ogg Vorbis I don't yet know about, and I suspect most of the other compressed formats will be more like MP3 than FLAC. Either way I don't see making On-demand work with the ffmpeg compressed formats as a priority - it is (from my point of view) much more useful to sort out choosing the right importer so that as much as possible goes through libsndfile (including using libsndfile for FLAC if it's built with FLAC support). Richard ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Audacity-devel mailing list Audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
|
Gale Andrews
|
| From "Michael Chinen" <mchinen@...> | Wed, 2 Jul 2008 14:46:06 -0400 | Subject: [Audacity-devel] OD turned off in latest alpha? Hi Michael > Gale, yes, I saw your comment on the wiki and liked the "Loading - > click to..." idea. The reason it's called on-demand is because In the > future once you click on a section it'll start loading from that > point. So maybe something like "Loading Waveform Image - click to > load immediately". That way the user might get the idea that it is > just the image that is loading and they can play/edit it as normal > while the OD loading is underway. Yes, "Loading Waveform Image" is quite good I think. The rest of the description needs thought. Given the unfamiliarity of this idea, I think as well as telling them they can click anywhere to jump loading to that point, they still need to know explicitly they can play and edit at once. For example, if they made a large selection at the end of the file to start load from there, they should know they don't have to wait for it to load. "Loading Waveform Image: Play or edit anywhere, or click to start load" might be a bit long though. Depends if having it (say) three times as a background is enough. > > I'd certainly hope that OD could work for as many file types as > > possible (presumably they have to be seekable?); and as I said before > > it's a considerable weakness that you can't leave the import filter set > > to "FFmepg-compatible files" and then "load on demand" a routine > > PCM WAV file. > We can do something even if it is not seekable, although the > on-demandness will lessen and we will just get background loading with > the user being able to immediately edit the parts that have been > loaded. Those cases will be very different from the current OD tasks, > since right now we have the real audio data in an aliased file from > the start, so we know things like definite length, etc. > > Richard: Either way I don't see making On-demand work with the ffmpeg > compressed formats as a priority - it is (from my point of view) much more > useful to sort out choosing the right importer so that as much as possible > goes through libsndfile (including using libsndfile for FLAC if it's built > with FLAC support). For my immediate problem, it seems I don't have the issue I thought I did, because I can use the "All supported files" filter. Then I get on-demand PCM import for WAV if Preferences are set to "read directly", but still get a normal WMA import via FFmpeg. That was my mistake, but I think the confusion is invited by including formats that Audacity supports natively in the "FFmpeg-compatible" filter, so I'm suggesting like Richard, why use FFmpeg to import WAV? Same goes for export (though I know we're testing the FFmpeg exporter). So for both import and export, why not reserve the "FFmpeg-compatible" filter for non-native formats, and possibly rename appropriately (e.g. "Other files, using FFmpeg")? We still have LRN's "Other FFmpeg-compatible files" dialogue if someone must export WAV via FFmpeg (that could be called something like "Custom format and codec using FFmpeg"). Also agree with Richard that the above is more of a priority than getting OD to work with uncompressed files. I still think OD with uncompressed files would be useful (even though less functional), and avoids user confusion over why some formats load with a familiar progress dialogue and some don't. But if MP3 proves insuperable/offers minimal time savings compared to normal loading, then perhaps it's better to keep it simple and restrict load-on-demand to uncompressed? Thanks Gale ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Audacity-devel mailing list Audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
|
Michael Chinen
|
2008/7/3 Gale Andrews <gale@...>:
> Also agree with Richard that the above is more of a priority than getting > OD to work with uncompressed files. I still think OD with uncompressed > files would be useful (even though less functional), and avoids user > confusion over why some formats load with a familiar progress dialogue > and some don't. But if MP3 proves insuperable/offers minimal time > savings compared to normal loading, then perhaps it's better to keep it > simple and restrict load-on-demand to uncompressed? I agree the priority should be towards uncompressed files. However I still need more convincing that it wouldn't be very useful for compressed formats like mp3. most mp3 players are a good example of how on-demand can work for compressed formats- when you load an mp3 player - you can open an mp3 for the first time and can see the length, and immediately start skipping around to any part of the file. As Richard pointed out, there are a lot of things in the format that make this complicated that need to be worked out. I think if we develop a non-aliased on-demand blockfile that doesn't allow certain effects and returns zeros for ReadData() until load,it will be efficient enough. How does it sound? Michael ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Audacity-devel mailing list Audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
James Crook
|
Michael,
I've made a tiny fix, a nit rather than a real problem, in sequence.cpp, changing '-b-1' to '-1-b'. Why? Because b is unsigned, so '-b' is also unsigned, so -b-1 is actually a very large number. It all worked before because when that's converted to an int the large number is treated as negative, but swapping the order is better practice and fixes a warning. In latest CVS the green blobs still only progress if we are doing something to cause repaints, e.g. dragging the size/height of the wave. In your block-update-code you should check the time after reading each block, and force some painting if it's been a while (0.2s?) and is needed. This would make it a lot clearer what's going on. For me this is more urgent than the other extensions. Could you also look at these warnings (below) and fix the ones which belong to you? Thanks. --James 3>------ Build started: Project: Audacity, Configuration: Unicode Debug Win32 ------ 3>Compiling... 3>AudacityHeaders.cpp 3>c:\sourceforge\audacity\src\waveclip.h(223) : warning C4251: 'WaveClip::mWaveCacheMutex' : class 'ODLock' needs to have dll-interface to be used by clients of class 'WaveClip' 3> c:\sourceforge\audacity\src\ondemand\odtaskthread.h(124) : see declaration of 'ODLock' 3>Compiling... 3>ODWaveTrackTaskQueue.cpp 3>c:\sourceforge\audacity\src\ondemand\odwavetracktaskqueue.cpp(32) : warning C4018: '<' : signed/unsigned mismatch 3>c:\sourceforge\audacity\src\ondemand\odwavetracktaskqueue.cpp(46) : warning C4018: '<' : signed/unsigned mismatch 3>c:\sourceforge\audacity\src\ondemand\odwavetracktaskqueue.cpp(83) : warning C4018: '<' : signed/unsigned mismatch 3>c:\sourceforge\audacity\src\ondemand\odwavetracktaskqueue.cpp(98) : warning C4018: '<' : signed/unsigned mismatch 3>c:\sourceforge\audacity\src\ondemand\odwavetracktaskqueue.cpp(112) : warning C4018: '<' : signed/unsigned mismatch 3>ODTaskThread.cpp 3>c:\sourceforge\audacity\src\ondemand\odtaskthread.cpp(48) : warning C4305: 'argument' : truncation from 'double' to 'float' 3>ODTask.cpp 3>c:\sourceforge\audacity\src\ondemand\odtask.cpp(28) : warning C4273: 'wxEVT_ODTASK_COMPLETE' : inconsistent dll linkage 3> c:\sourceforge\audacity\src\ondemand\odtask.cpp(27) : see previous definition of 'wxEVT_ODTASK_COMPLETE' 3>ODManager.cpp 3>c:\sourceforge\audacity\src\ondemand\odmanager.cpp(27) : warning C4273: 'wxEVT_ODTASK_UPDATE' : inconsistent dll linkage 3> c:\sourceforge\audacity\src\ondemand\odmanager.cpp(26) : see previous definition of 'wxEVT_ODTASK_UPDATE' 3>c:\sourceforge\audacity\src\ondemand\odmanager.cpp(46) : warning C4018: '<' : signed/unsigned mismatch 3>c:\sourceforge\audacity\src\ondemand\odmanager.cpp(63) : warning C4018: '<' : signed/unsigned mismatch 3>c:\sourceforge\audacity\src\ondemand\odmanager.cpp(241) : warning C4018: '<' : signed/unsigned mismatch 3>c:\sourceforge\audacity\src\ondemand\odmanager.cpp(270) : warning C4018: '<' : signed/unsigned mismatch 3>c:\sourceforge\audacity\src\ondemand\odmanager.cpp(282) : warning C4018: '<' : signed/unsigned mismatch 3>ODComputeSummaryTask.cpp 3>c:\sourceforge\audacity\src\ondemand\odcomputesummarytask.cpp(160) : warning C4018: '<' : signed/unsigned mismatch 3>c:\sourceforge\audacity\src\ondemand\odcomputesummarytask.cpp(165) : warning C4018: '<' : signed/unsigned mismatch 3>c:\sourceforge\audacity\src\ondemand\odcomputesummarytask.cpp(173) : warning C4018: '<' : signed/unsigned mismatch 3>Sequence.cpp 3>c:\sourceforge\audacity\src\sequence.cpp(1038) : warning C4146: unary minus operator applied to unsigned type, result still unsigned 3>c:\sourceforge\audacity\src\sequence.cpp(1051) : warning C4146: unary minus operator applied to unsigned type, result still unsigned 3>NoteTrack.cpp 3>c:\sourceforge\audacity\src\notetrack.cpp(262) : warning C4101: 'parameters' : unreferenced local variable 3>AudioIO.cpp 3>c:\sourceforge\audacity\src\audioio.cpp(1513) : warning C4800: 'PaError' : forcing value to bool 'true' or 'false' (performance warning) 3>Generating Code... 3>Compiling... 3>SoundActivatedRecord.cpp 3>Linking... 3> Creating library C:\Sourceforge\audacity\win\Unicode Debug\Audacity.lib and object C:\Sourceforge\audacity\win\Unicode Debug\Audacity.exp 3>Project.obj : warning LNK4049: locally defined symbol ?wxEVT_ODTASK_COMPLETE@@3HB (int const wxEVT_ODTASK_COMPLETE) imported 3>Project.obj : warning LNK4049: locally defined symbol ?wxEVT_ODTASK_UPDATE@@3HB (int const wxEVT_ODTASK_UPDATE) imported 3>Embedding manifest... 3>Build log was saved at "file://c:\Sourceforge\audacity\win\Projects\Audacity\Unicode Debug\BuildLog.htm" 3>Audacity - 0 error(s), 30 warning(s) ========== Build: 3 succeeded, 0 failed, 17 up-to-date, 0 skipped ========== ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Audacity-devel mailing list Audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
|
Michael Chinen
|
2008/7/5 James Crook <crookj@...>:
> Michael, > > I've made a tiny fix, a nit rather than a real problem, in sequence.cpp, > changing '-b-1' to '-1-b'. Why? Because b is unsigned, so '-b' is also > unsigned, so -b-1 is actually a very large number. It all worked before > because when that's converted to an int the large number is treated as > negative, but swapping the order is better practice and fixes a warning. Okay, thanks. > In latest CVS the green blobs still only progress if we are doing > something to cause repaints, e.g. dragging the size/height of the wave. > In your block-update-code you should check the time after reading each > block, and force some painting if it's been a while (0.2s?) and is > needed. This would make it a lot clearer what's going on. For me this > is more urgent than the other extensions. James, I went ahead and made this change so now it happens about twice a second. The reason I didn't want 0.2s is because redrawing is really really expensive - Audacity isn't using dirty regions, so it redraws the whole waveform. This is unrelated to the wavecache modifications I made - I implemented invalid regions so that we don't have to hit the blockfiles/audio data for each block upon a redraw with new data. On my intel imac it isn't a problem, but it is very slow on my powerbook g4. I think this should be a user defined setting since the user-specific cpu power directly affects the user experience with auto redraws (we've never had it before for waveforms) > Could you also look at these warnings (below) and fix the ones which > belong to you? Thanks. These should be fixed with my changes, but I can't see them in xcode to begin with. Michael ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ audacity-devel mailing list audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
Martyn Shaw-2
|
Michael Chinen wrote: > 2008/7/5 James Crook <crookj@...>: >> Michael, ... >> In latest CVS the green blobs still only progress if we are doing >> something to cause repaints, e.g. dragging the size/height of the wave. >> In your block-update-code you should check the time after reading each >> block, and force some painting if it's been a while (0.2s?) and is >> needed. This would make it a lot clearer what's going on. For me this >> is more urgent than the other extensions. > James, I went ahead and made this change so now it happens about twice a second. It's still not updating here, unless I do something. XP SP2 VS8. Martyn ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ audacity-devel mailing list audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
|
Michael Chinen
|
2008/7/8 Martyn Shaw <martynshaw99@...>:
> It's still not updating here, unless I do something. XP SP2 VS8. >From the way this was worded I want to ask explicitly - It hasn't ever updated automatically on windows? It seems to be broken on macs too now, but it worked up to a while ago at once every four seconds. looking into it. Michael ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ audacity-devel mailing list audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
|
Michael Chinen
|
2008/7/8 Michael Chinen <mchinen@...>:
> 2008/7/8 Martyn Shaw <martynshaw99@...>: >> It's still not updating here, unless I do something. XP SP2 VS8. Can you try it again? It works on mac with my latest commit. ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ audacity-devel mailing list audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
|||||||||||||||
| Free Forum Powered by Nabble | Forum Help |