Implemented option, in batch process, to export sound until just after last loop as separate attack.
Updated copyright year. Updated help file for the pitch dialog and added screenshots of the new fft power spectrum dialog.
Ensured correct power of two with rounding and fixed background style of panel to get the fft spectrum display working under windows.
Implemented possibility to view fft power spectrum of audio data and set pitch from it.
Added batch process to export audio data from last cue marker in file as a (separate) release.
Updated external libraries to current releases and adjusted build system and source code accordingly.
Prevent crash when loopsearching caused by sustainstart set too early.
Include all channels in loop detection/evaluation. Added automatic cue detection in batch.
Change playback mode to loop playback when a new loop is selected.
Update the batch process textctrl with results continuously.
Corrected pitch fraction line specifications for a GO odf.
Changed pitch listings in batch to include all files in directory and corrected line to PitchCorrection
Made batch processing LIST info remember strings.
Fixed focus on OK button in pitch dialog.
Fixed loop creation to not possibly be invalid.
Select the newly created loop.
Updated copyright year.
LoopAuditioneer crashes in batch mode
Silence lots of unused compiler warnings
Add resources for MSW build
Fix depracated warnings for wxPen and wxBrush
Fix grid re-sizing issue on MSW
Added cmake build system. Restructured repository layout. New icons.
I asked about static casts and if to use get event object to know if I could use them to make a patch to fix the warnings issue because of the unused event argument in event handlers. static casts costs nothing since it's a compile time thing; c style casts are discouraged in c++, then using them for get event object, which I see is always same as the requested widget, would silent the unused argument warnings. Otherwise just remove the event argument from the function would do.
I've fixed the compiler warnings for now. With LA built on Ubuntu with wx 3.0.5 the window positioning and size is correctly stored and restored. I really suspect a wx issue/bug why it's not for you. Using the ID with FindWindow() vs event.GetEventObject() is really only needed outside direct events (when handling more than one control) or if there possibly could be any confusion about which control should be dealt with. I don't really see any reason to worry about it though. Changing the way of...
Fix compiler warnings.
From your screenshot I guess that is the best you can do with 3.0.x, which lacks some fixes in 3.1.x for dark themes, in my case it works fine, probably the theme I'm using takes more the text color into account than others, IDK. Anyway I tested your last changes in r64 and the colors and the popup menu are OK here, though the window position is not working, and I don't understand why, though I haven't dig into the issue much. About the wxEVT_MOVE family looks like there were some error in documentation...
From your screenshot I guess that is the best you can do with 3.0.x, which lacks some fixes in 3.1.x for dark themes, in my case it works fine, probably the theme I'm using takes more the text color into account than others, IDK. Anyway I tested your last changes in r64 and the colors and the popup menu are OK here, though the window position is not working, and I don't understand why, though I haven't dig into the issue much. About the wxEVT_MOVE family looks like there were some error in documentation...
Fix window position saving and some (waveform)display related issues.
this doesn't sound to be true For the stable 3.0.5 it is, read the documentation. For dev. it's true for child windows under wxGTK, not top level. Anyway, there's a much easier fix for this that don't depend on any event detection. wxGrid was selected because it's the natural choice. From the manual: wxGrid and its related classes are used for displaying and editing tabular data. The listctrl (which the listview uses in background) was selected for displaying the file list - and it has its own problems....
wxMoveEvent is only used by MSW so it's not really useful. this doesn't sound to be true, I recall I used it in the past and as I said in the OP it worked, I'm using Archlinux, it saves the position when moved before closing, though it doesn't fix the original issue. Changing to a dark theme on Ubuntu 20.04 destroy the listctrl readability completely. Dark theme is something that doesn't work but not even a problem on Windows, at least up to 10, but it's used on Linux and macOS. Usually the solution...
wxMoveEvent is only used by MSW so it's not really useful. this doesn't sound to be true, I recall I used it in the past and as I said in the OP it worked, I'm using Archlinux, it saves the position when moved before closing, though it doesn't fix the original issue. Changing to a dark theme on Ubuntu 20.04 destroy the listctrl readability completely. Dark theme is something that doesn't work but not even a problem on Windows, at least up to 10, but it's used on Linux and macOS. Usually the solution...
wxMoveEvent is only used by MSW so it's not really useful. this doesn't sound to be true, I recall I used it in the past and as I said in the OP it worked, I'm using Archlinux, it saves the position when moved before closing, though it doesn't fix the original issue. Changing to a dark theme on Ubuntu 20.04 destroy the listctrl readability completely. Dark theme is something that doesn't work but not even a problem on Windows, at least up to 10, but it's used on Linux and macOS. Usually the solution...
Popup menu position corrected in r63. wxMoveEvent is only used by MSW so it's not really useful. I have another simple solution for that. I'll work on the background and test some things - other issues occur if I just remove it. Changing to a dark theme on Ubuntu 20.04 destroy the listctrl readability completely.
Fix popup menu position
UI issues
Sounds promising! Many thanks for considering. this idea.
As I see it, there could be two possible ways to do this without loosing the visual advantages from the waveform overlay in its own "window". Either one could add a possibility to access playback from within the overlay dialog that's currently modal, or the other possibility would be to not have the waveform overlay as a modal dialog at all but instead a modeless, thus permitting to have it opened while still doing things also in the main frame. Both options requires some serious re-work though....
[Feature Request] Play samples while the "Waveform overlay of loops" is open
Fantastic! This makes it so much easier to see the current loop if there are many of them. Many thanks!
LoopAuditioneer 0.8.8 is released
[Feature Request] Mark currently selected loop and CUE marker in waveform display
Added with commit 62.
Indicate on waveform what loop or cue is selected, updated help
I'll look into it, though it will make a redraw of at least part of the waveform display necessary every time another loop or cue is selected.
[Feature Request] Mark currently selected loop and CUE marker in waveform display
[Bug Report] CUE list outside visible space when opening a file
[Feature Request] Scroll through all files of a rank with the arrow keys
LoopAuditioneer 0.8.7 is released
Add options to directly open previous or next file from currently selected
I'll add the other new feature to close/step/open next or previous file too and then make a new release.
I have seen that you have already updated the source code. When do you place new builds in the "Files" section?
[Bug Report] LoopAuditioneer writes rarely used chunks in WAV file
Make proportions even between loop and cue grid
Ok, the layout proportions should be improved. I think it's a very easy fix.
What speaks against opening the corresponding loops automatically when pressing X (or S)? Safety consideration. Not only loops are opened - the whole file is loaded into memory when the file is opened (Ctrl+F). Consider what would happen if there are changes done to the current file and another is loaded - all changes would be discarded. And no, I won't add a dialog asking: File is changed. Are you really sure you want to open another one? The operation you suggest would be the same as if a single...
[Bug Report] CUE list outside visible space when opening a file
These are actually still two (or better three keys), which have to be pressed. X (or S) and then Ctrl-F is not very convenient (with and without Ctrl key). What speaks against opening the corresponding loops automatically when pressing X (or S)?
All file I/O operations of LoopAuditioneer happen via libsndfile. Of the mentioned chunks the only one that LA sometimes intentionally writes is the LIST INFO. How the other chunks get there I don't know...
Actually, this is already possible. After you've selected a working folder the filelist will be populated and the top file selected. Then you can navigate down with the "X" key and up with "S". Then to open the selected file you press Ctrl+F and you'll see the loops and cues inside. Note, you can navigate the loop list independently with the "D" and "C" keys. All this is documented in the help under "Keyboard shortcuts". The help can be reached with F1.
[Bug Report] LoopAuditioneer writes rarely used chunks in WAV file
[Feature Request] Scroll through all files of a rank with the arrow keys
LoopAuditioneer fails to show more than 16 loops
Added check to not try importing more than 16 loops in rev 59.
add check to not try importing more than 16 loops
Well, it's not directly a bug but poor design in some ways... Libsndfile, that is used for the file I/O handling, can only deal with 16 loops. Internally, LoopAuditioneer can handle more than 16 loops ,but only 16 will (or should) be saved. In the files you've attached there's garbage start/end information for the loops above 16, don't know if it's actually garbage in the file or if it's caused by libsndfile trying to read more loops than it can handle. However, I think that I'll have to implement...
I don't have access to any macOS computer so I cannot test it. However, since the time that instruction was published (by someone else than me) quite a few things have changed with LoopAuditioneer so you'll have to check the current build instruction for Linux and make necessary changes to the instruction above (include among other possible things adding the libsamplerate building and the additional files to be compiled). Test and report.
LoopAuditioneer fails to show more than 16 loops
Compiling LoopAuditioneer for macOS
add very basic looppoint detection as suggestion when manually creating a new loop
Thanks, I was looking for a tool called trim but realised after your reply that it's the Remove sound between last loop and cue option.
How to batch trim
Trim away unused sample data only works in batch mode (gear icon). Test it by creating copies (target folder another than original!), but I think it leaves 3 sample frames after last loop point and then trim away right up to release cue. The best way to contribute to the project is by using the software, giving feedback on it, suggesting possible improvements and generally testing things. Ideally, if the samples you produce with it gives other people joy using them, no greater reward could be gi...
How to batch trim
fix some layout related issues, better default values to add a loop dialog
changed sustainsection indication on waveform, added possibility to change it on waveform if not on autodetect
Excellent, thank you!
LA crashes with attempted use of Pitch Information function
Binary glib library conflict
Multichannel files
The 0.8.6 version should now handle the audio stream so that if too many channels exist in the audio file the device will only try playing back the number it can handle. The excess channels won't be played at all.
LoopAuditioneer 0.8.6 is released
updated copyright, fix crash, add sound api/device handling, add resampling if needed, updated help
Most of the time I only need to hear the first channel (close mic) so if there was a way to turn off the other channels or down mix that would be great. BTW I reimplemented some of your loop search algorithm as a lua script in Ardour - https://www.youtube.com/watch?v=-LZ4Rvf4ITM
No, it won't work since LA tries to open the audio stream with the exact number of channels in the file and likely silently fails. Currently there's no check to find the limitations of channel numbers of the device. I'll either have to implement it now that I'm reworking audio output or add some kind of downmix feature.
Hello, No my output device is stereo. Shouldn't I still hear the audio from the first two channels?
Does your default audio device have that many channels? LA presently doesn't do any downmixing on its own, but just attempts to open the audio stream with the number of channels present in the file regardless of your device actual channel numbers. Anyway, I'm currently reworking the audio system of LA.