sv1-devel Mailing List for Sonic Visualiser
Brought to you by:
cannam
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(140) |
Jun
(112) |
Jul
(33) |
Aug
(15) |
Sep
(2) |
Oct
(6) |
Nov
(7) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(22) |
Feb
(12) |
Mar
(68) |
Apr
(38) |
May
(33) |
Jun
(32) |
Jul
(15) |
Aug
(36) |
Sep
(4) |
Oct
(34) |
Nov
(22) |
Dec
(75) |
2008 |
Jan
(12) |
Feb
(58) |
Mar
(16) |
Apr
(8) |
May
(13) |
Jun
(7) |
Jul
(2) |
Aug
(3) |
Sep
(2) |
Oct
(3) |
Nov
(1) |
Dec
(4) |
2009 |
Jan
|
Feb
(19) |
Mar
(32) |
Apr
(1) |
May
(2) |
Jun
(4) |
Jul
(11) |
Aug
(7) |
Sep
(6) |
Oct
(3) |
Nov
(3) |
Dec
(8) |
2010 |
Jan
(8) |
Feb
(3) |
Mar
(2) |
Apr
|
May
(6) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
(1) |
Oct
(10) |
Nov
(4) |
Dec
(2) |
2011 |
Jan
|
Feb
|
Mar
(6) |
Apr
(3) |
May
(2) |
Jun
|
Jul
(3) |
Aug
(3) |
Sep
(5) |
Oct
(4) |
Nov
(1) |
Dec
|
2012 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(2) |
2013 |
Jan
(1) |
Feb
(5) |
Mar
(12) |
Apr
(4) |
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(6) |
2014 |
Jan
|
Feb
(13) |
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
2019 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
(5) |
2021 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <me...@in...> - 2021-01-20 23:55:26
|
<div>Dear Christofer,</div><div> </div><div><div>I believe sample values proportional to pressure on microphones which we measure as voltage/current and call it amplitude values, hence the formula with the factor of 20 applies. / power goes as the square of the pressure then factor of 10 applies.<br /><br />I reviewed that Sonic Visualiser uses also "20 * log10" in some cases - did not check yet when and why.<br />I am not familiar with Adobe Audition and its settings.<br />I will try and see if I can get the same results as you.<br />Could you specify what versions ( S.Visualiser and A.Audition ) you work on.<br /><br />Note: I am also a student / please correct me any time.<br /> </div><div>Regards</div><div>Mehmet</div></div><div> </div><div>20.01.2021, 21:38, "Christofer Bustad" <tos...@ho...>:</div><blockquote><div><div style="color:rgb( 0 , 0 , 0 );font-family:'calibri' , 'helvetica' , sans-serif;font-size:12pt">Dear Mehmet,<div> </div><div>Thanks a lot for your e-mail, the lines of code and the link. That is exactly my question. Is not the sample values proportional to the voltage? Then according to this website, 20 should be used instead of 10? Or am I misunderstanding what you mean? Thank you in advance!</div><div> </div><div>Best regards,</div> Christofer</div><div><div> </div><div style="color:rgb( 0 , 0 , 0 );font-family:'calibri' , 'helvetica' , sans-serif;font-size:12pt"> </div><hr style="width:98%" /><div><font color="#000000" face="Calibri, sans-serif" style="font-size:11pt"><strong>From:</strong> <a href="mailto:me...@in..." rel="noopener noreferrer">me...@in...</a> <<a href="mailto:me...@in..." rel="noopener noreferrer">me...@in...</a>><br /><strong>Sent:</strong> 20 January 2021 18:32<br /><strong>To:</strong> Christofer Bustad <<a href="mailto:tos...@ho..." rel="noopener noreferrer">tos...@ho...</a>>; <a href="mailto:sv1...@li..." rel="noopener noreferrer">sv1...@li...</a> <<a href="mailto:sv1...@li..." rel="noopener noreferrer">sv1...@li...</a>><br /><strong>Subject:</strong> Re: [Sv1-devel] dBFS</font><div> </div></div><div><div>Hello,</div><div> </div><div>Well, if you check the source code of Sonic Visualiser you could spot this lines..</div><div><div>AudioLevel - float dB = 10 * log10f(multiplier);</div></div><div><div>SpectrumLayer - value = 10.f * log10f(value);</div><div> </div><div>so if you are saying why does Sonic Visualiser use 10 instead 20 you may check here :<br /><br /><a href="https://www.cds.caltech.edu/~murray/wiki/index.php/Why_is_dB_defined_as_20log_10%3F" rel="noopener noreferrer">https://www.cds.caltech.edu/~murray/wiki/index.php/Why_is_dB_defined_as_20log_10%3F</a></div><div> </div><div> </div></div><div> </div><div>Regards,</div><div>Mehmet</div><div> </div><div>20.01.2021, 17:12, "Christofer Bustad" <<a href="mailto:tos...@ho..." rel="noopener noreferrer">tos...@ho...</a>>:</div><blockquote><div><div style="color:rgb( 0 , 0 , 0 );font-family:'calibri' , 'helvetica' , sans-serif;font-size:12pt">Hi there,<div> </div><div>Thank you to all who contributed to this great and very useful piece of open-source software.</div><div> </div><div>I wonder if someone may help me to understand something... If I generate a pure sine wave at say -20 dBFS in Adobe Audition, Sonic Visualiser displays the level -10 dBFS in the waveform view. Similarly, if I generate a sine wave at -40 dBFS in Adobe Audition, Sonic Visualiser displays the level -20 dBFS. Could it be the case that Sonic Visualiser calculates the dB values using 10*log10(input)? It was my understanding that dB values usually are calculated from sample values using 20*log10(input). <span style="background-color:#ffffff">Am I missing something in my understanding of this or </span>could this be a bug in Sonic Visualiser? There also seems to be a similar difference in the spectrum view when I compare Sonic Visualiser to Adobe Audition.</div><div> </div><div>Thank you very much in advance!</div><div> </div><div>Best regards,</div> Christofer</div><div style="color:rgb( 0 , 0 , 0 );font-family:'calibri' , 'helvetica' , sans-serif;font-size:12pt"> </div></div>,,<p style="margin-bottom:0;margin-top:0">_______________________________________________<br />Sv1-devel mailing list<br /><a href="mailto:Sv1...@li..." rel="noopener noreferrer">Sv1...@li...</a><br /><a href="https://lists.sourceforge.net/lists/listinfo/sv1-devel" rel="noopener noreferrer">https://lists.sourceforge.net/lists/listinfo/sv1-devel</a></p></blockquote></div></div></div></blockquote> |
From: Christofer B. <tos...@ho...> - 2021-01-20 18:38:24
|
Dear Mehmet, Thanks a lot for your e-mail, the lines of code and the link. That is exactly my question. Is not the sample values proportional to the voltage? Then according to this website, 20 should be used instead of 10? Or am I misunderstanding what you mean? Thank you in advance! Best regards, Christofer ________________________________ From: me...@in... <me...@in...> Sent: 20 January 2021 18:32 To: Christofer Bustad <tos...@ho...>; sv1...@li... <sv1...@li...> Subject: Re: [Sv1-devel] dBFS Hello, Well, if you check the source code of Sonic Visualiser you could spot this lines.. AudioLevel - float dB = 10 * log10f(multiplier); SpectrumLayer - value = 10.f * log10f(value); so if you are saying why does Sonic Visualiser use 10 instead 20 you may check here : https://www.cds.caltech.edu/~murray/wiki/index.php/Why_is_dB_defined_as_20log_10%3F Regards, Mehmet 20.01.2021, 17:12, "Christofer Bustad" <tos...@ho...>: Hi there, Thank you to all who contributed to this great and very useful piece of open-source software. I wonder if someone may help me to understand something... If I generate a pure sine wave at say -20 dBFS in Adobe Audition, Sonic Visualiser displays the level -10 dBFS in the waveform view. Similarly, if I generate a sine wave at -40 dBFS in Adobe Audition, Sonic Visualiser displays the level -20 dBFS. Could it be the case that Sonic Visualiser calculates the dB values using 10*log10(input)? It was my understanding that dB values usually are calculated from sample values using 20*log10(input). Am I missing something in my understanding of this or could this be a bug in Sonic Visualiser? There also seems to be a similar difference in the spectrum view when I compare Sonic Visualiser to Adobe Audition. Thank you very much in advance! Best regards, Christofer ,, _______________________________________________ Sv1-devel mailing list Sv1...@li...<mailto:Sv1...@li...> https://lists.sourceforge.net/lists/listinfo/sv1-devel |
From: <me...@in...> - 2021-01-20 17:48:17
|
<div>Hello,</div><div> </div><div>Well, if you check the source code of Sonic Visualiser you could spot this lines..</div><div><div>AudioLevel - float dB = 10 * log10f(multiplier);</div></div><div><div>SpectrumLayer - value = 10.f * log10f(value);</div><div> </div><div>so if you are saying why does Sonic Visualiser use 10 instead 20 you may check here :<br /><br />https://www.cds.caltech.edu/~murray/wiki/index.php/Why_is_dB_defined_as_20log_10%3F</div><div> </div><div> </div></div><div> </div><div>Regards,</div><div>Mehmet</div><div> </div><div>20.01.2021, 17:12, "Christofer Bustad" <tos...@ho...>:</div><blockquote><div><div style="color:rgb( 0 , 0 , 0 );font-family:'calibri' , 'helvetica' , sans-serif;font-size:12pt">Hi there,<div> </div><div>Thank you to all who contributed to this great and very useful piece of open-source software.</div><div> </div><div>I wonder if someone may help me to understand something... If I generate a pure sine wave at say -20 dBFS in Adobe Audition, Sonic Visualiser displays the level -10 dBFS in the waveform view. Similarly, if I generate a sine wave at -40 dBFS in Adobe Audition, Sonic Visualiser displays the level -20 dBFS. Could it be the case that Sonic Visualiser calculates the dB values using 10*log10(input)? It was my understanding that dB values usually are calculated from sample values using 20*log10(input). <span style="background-color:#ffffff">Am I missing something in my understanding of this or </span>could this be a bug in Sonic Visualiser? There also seems to be a similar difference in the spectrum view when I compare Sonic Visualiser to Adobe Audition.</div><div> </div><div>Thank you very much in advance!</div><div> </div><div>Best regards,</div> Christofer</div><div style="color:rgb( 0 , 0 , 0 );font-family:'calibri' , 'helvetica' , sans-serif;font-size:12pt"> </div></div>,,<p>_______________________________________________<br />Sv1-devel mailing list<br /><a href="mailto:Sv1...@li..." rel="noopener noreferrer">Sv1...@li...</a><br /><a href="https://lists.sourceforge.net/lists/listinfo/sv1-devel" rel="noopener noreferrer">https://lists.sourceforge.net/lists/listinfo/sv1-devel</a></p></blockquote> |
From: Christofer B. <tos...@ho...> - 2021-01-20 14:12:10
|
Hi there, Thank you to all who contributed to this great and very useful piece of open-source software. I wonder if someone may help me to understand something... If I generate a pure sine wave at say -20 dBFS in Adobe Audition, Sonic Visualiser displays the level -10 dBFS in the waveform view. Similarly, if I generate a sine wave at -40 dBFS in Adobe Audition, Sonic Visualiser displays the level -20 dBFS. Could it be the case that Sonic Visualiser calculates the dB values using 10*log10(input)? It was my understanding that dB values usually are calculated from sample values using 20*log10(input). Am I missing something in my understanding of this or could this be a bug in Sonic Visualiser? There also seems to be a similar difference in the spectrum view when I compare Sonic Visualiser to Adobe Audition. Thank you very much in advance! Best regards, Christofer |
From: Paul C. <che...@gm...> - 2019-12-08 10:44:44
|
Good points! Glad to learn about the history of this great project. I break up the sounds sampled from a metronome. Each sound wave within that time period is not big so I can extract peak frequencies of each sample using the spectrum UI. From them I can analyze the music notes being played from each sample sound. All are done manually. So I'm hoping to find a way to automate the manual steps. Now it looks like I need to hack the code to make that happen? Thanks for comments On Thu, Dec 5, 2019 at 2:43 AM Chris Cannam <ca...@al...> wrote: > Hi Paul, Rainer - > > On Fri, 29 Nov 2019, at 15:25, Rainer Josef SCHWOB wrote: > > "Export Audio to Data File" does not save the Spectogram or another > > analysis, but the original audio data. I'm not sure for whom this > > feature was created as it results in very, very big text files with > > exactly the same information as in the previously loaded binary .wav > > file (but if you export ca. 1 sec., import it in Excel and make a line > > chart there, you can see the waveform). > > As your example suggests, it's mostly useful for exporting very short > selections for analysis in some non-audio tool, rather than exporting the > whole of a long audio file. > > There is currently no way to export the contents of a spectrogram layer. > Depending on the type of spectrogram, you may be able to run it in a plugin > and then export the contents of the 3d plot layer that shows the plugin > output. > > This is undoubtedly a feature that ought to be there. There are a couple > of reasons why it wasn't added at the same time as exporting other kinds of > layer. > > One is tediously technical - the export function exports whatever internal > model the layer is formally a view of, but the spectrogram layer is > formally another view of the waveform data (it just uses another model for > conversion internally) so a naive implementation would end up exporting > time-domain data rather than spectrograms! > > Another line of thought was just that spectrogram data may be rather large > to be exported as text. But that was before the ability to export plain > audio as text was added, and that's of a similar size. And of course any > plugin can produce equally bulky output that can be exported. > > > Chris > > > _______________________________________________ > Sv1-devel mailing list > Sv1...@li... > https://lists.sourceforge.net/lists/listinfo/sv1-devel > |
From: Chris C. <ca...@al...> - 2019-12-05 11:54:21
|
On Wed, 20 Nov 2019, at 00:40, ornx via Sv1-devel wrote: > In the latest version of Sonic Visualiser, INSTALL.txt says MAD, oggz, > and fishsound are optional dependencies, but in configure.ac they are > marked as required. Below is a patch which fixes that. Hi there - Thanks for the feedback here. This was actually a deliberate change in configure.ac recently. It was proving too much of a liability to have the build process produce builds with different levels of audio file support based on an environment that could be accidental (builder forgot to install a certain development header) rather than based on any explicit decision made at build time. So the bug really is that the documentation is out of date - I've updated it and pushed the change. Chris |
From: Chris C. <ca...@al...> - 2019-12-05 10:43:24
|
Hi Paul, Rainer - On Fri, 29 Nov 2019, at 15:25, Rainer Josef SCHWOB wrote: > "Export Audio to Data File" does not save the Spectogram or another > analysis, but the original audio data. I'm not sure for whom this > feature was created as it results in very, very big text files with > exactly the same information as in the previously loaded binary .wav > file (but if you export ca. 1 sec., import it in Excel and make a line > chart there, you can see the waveform). As your example suggests, it's mostly useful for exporting very short selections for analysis in some non-audio tool, rather than exporting the whole of a long audio file. There is currently no way to export the contents of a spectrogram layer. Depending on the type of spectrogram, you may be able to run it in a plugin and then export the contents of the 3d plot layer that shows the plugin output. This is undoubtedly a feature that ought to be there. There are a couple of reasons why it wasn't added at the same time as exporting other kinds of layer. One is tediously technical - the export function exports whatever internal model the layer is formally a view of, but the spectrogram layer is formally another view of the waveform data (it just uses another model for conversion internally) so a naive implementation would end up exporting time-domain data rather than spectrograms! Another line of thought was just that spectrogram data may be rather large to be exported as text. But that was before the ability to export plain audio as text was added, and that's of a similar size. And of course any plugin can produce equally bulky output that can be exported. Chris |
From: Chris C. <ca...@al...> - 2019-12-05 10:28:14
|
On Mon, 2 Dec 2019, at 21:37, Paul Chen wrote: > After downloading Sonic Visualizer repo and brew install qt5, I got > qmake, etc. The steps > <https://github.com/sonic-visualiser/sonic-visualiser/blob/master/INSTALL.txt> to build the app seem very terse. What are the parameters I need to feed to qmake, Makefiles to use? Hi Paul - the steps there are pretty much right if you are building from a checkout of the Mercurial repo; the main thing that's missing is that you may need to run "qmake -r sonic-visualiser.pro" rather than just qmake -r, if you have checked out into a directory named something other than just sonic-visualiser. This is because qmake picks the project name from the current directory name by default, so if that differs from the project file name, it's necessary to specify a project file. So $ ./repoint install $ qmake -r sonic-visualiser.pro $ make (In my case the second step is more like "~/Qt/5.13.1/clang_64/bin/qmake -r sonic-visualiser.pro" since I don't install qmake into the PATH.) The correct Makefile is then simply called Makefile, it's just that it doesn't get generated until you run qmake on the appropriate project file. However if you are building from an official source package, then you will also need to make sure all the dependent libraries are installed and available first. I've just updated INSTALL.txt to list these (https://code.soundsoftware.ac.uk/projects/sonic-visualiser/repository/entry/INSTALL.txt?utf8=%E2%9C%93&rev=5ecb3a1c0ed3#L26). Chris |
From: Paul C. <che...@gm...> - 2019-12-02 21:37:25
|
Hi folks, After downloading Sonic Visualizer repo and brew install qt5, I got qmake, etc. The steps <https://github.com/sonic-visualiser/sonic-visualiser/blob/master/INSTALL.txt> to build the app seem very terse. What are the parameters I need to feed to qmake, Makefiles to use? * List of Makefiles: ./bqresample/Makefile ./bqresample/build/Makefile.inc ./bqresample/build/Makefile.osx.libsamplerate ./bqaudioio/Makefile ./piper-vamp-cpp/Makefile ./piper-vamp-cpp/ext/json11/Makefile ./bqaudiostream/Makefile ./vamp-plugin-sdk/skeleton/Makefile.osx ./vamp-plugin-sdk/skeleton/Makefile.inc ./vamp-plugin-sdk/build/Makefile.osx ./vamp-plugin-sdk/Makefile.in ./bqfft/Makefile ./bqfft/build/Makefile.osx ./bqfft/build/Makefile.inc ./bqvec/Makefile ./bqvec/build/Makefile.osx ./bqvec/build/Makefile.inc Thanks for comments |
From: Rainer J. S. <Rai...@mo...> - 2019-11-29 15:56:57
|
Hi Paul, "Export Audio to Data File" does not save the Spectogram or another analysis, but the original audio data. I'm not sure for whom this feature was created as it results in very, very big text files with exactly the same information as in the previously loaded binary .wav file (but if you export ca. 1 sec., import it in Excel and make a line chart there, you can see the waveform). Depending on your needs you could be happy with File | Export SVG File... (as SVG contains vector information in plain text). I do not know a way to save the data from SV's FFT analysis ("Export Annotation Layer" does not seem to be implemented for Spectogram Layers/Panes). As SV and most Vamp Plugins are open source, you could implement something for this purpose or read the fft data from the .sv file. But if you want to re-use FFT data in mathematical/statistic software like R(Studio), it is easier to calculate it directly there; e.g. for R[Studio] you could use the packages tuneR and signal, have a look at https://hansenjohnson.org/post/spectrograms-in-r/ (it's for analyzing whales, but works with Wagner and The Who too). Best regards, Rainer >>> Paul Chen <che...@gm...> 29.11.2019 02:36 >>> Hi folks, I'm new to this project and excited to learn about what it does. One quick question - what is the csv data exported by: File -> Export Audio to Data File I wanted to export peak frequency spectogram but it doesn't look like it. Thanks for comments Paul |
From: Paul C. <che...@gm...> - 2019-11-29 01:36:28
|
Hi folks, I'm new to this project and excited to learn about what it does. One quick question - what is the csv data exported by: File -> Export Audio to Data File I wanted to export peak frequency spectogram but it doesn't look like it. Thanks for comments Paul |
From: ornx <or...@pr...> - 2019-11-20 00:40:49
|
In the latest version of Sonic Visualiser, INSTALL.txt says MAD, oggz, and fishsound are optional dependencies, but in configure.ac they are marked as required. Below is a patch which fixes that. I would have posted to the bug tracker but sourceforge won't let me sign up. --- a/configure.ac 2019-11-19 19:34:00.708209416 -0500 +++ b/configure.ac 2019-11-19 19:34:07.948298892 -0500 @@ -121,9 +121,9 @@ SV_MODULE_OPTIONAL([libpulse],[libpulse >= 0.9],[pulse/pulseaudio.h],[pulse],[pa_stream_new]) SV_MODULE_REQUIRED([lrdf],[lrdf >= 0.2],[lrdf.h],[lrdf],[lrdf_init]) -SV_MODULE_REQUIRED([oggz],[oggz >= 1.0.0],[oggz/oggz.h],[oggz],[oggz_run]) -SV_MODULE_REQUIRED([fishsound],[fishsound >= 1.0.0],[fishsound/fishsound.h],[fishsound],[fish_sound_new]) -SV_MODULE_REQUIRED([mad],[mad >= 0.15.0],[mad.h],[mad],[mad_decoder_init]) +SV_MODULE_OPTIONAL([oggz],[oggz >= 1.0.0],[oggz/oggz.h],[oggz],[oggz_run]) +SV_MODULE_OPTIONAL([fishsound],[fishsound >= 1.0.0],[fishsound/fishsound.h],[fishsound],[fish_sound_new]) +SV_MODULE_OPTIONAL([mad],[mad >= 0.15.0],[mad.h],[mad],[mad_decoder_init]) SV_MODULE_REQUIRED([id3tag],[id3tag >= 0.15.0],[id3tag.h],[id3tag],[id3_tag_new]) SV_MODULE_REQUIRED([opus],[opusfile],[opus/opusfile.h],[opusfile],[op_read_float]) |
From: Chris C. <ca...@al...> - 2019-10-30 10:09:27
|
I'm delighted to announce new releases (made last Friday) of Sonic Visualiser and two related desktop applications from the Centre for Digital Music: Version 4.0 of Sonic Visualiser, a free, cross-platform, open source application for viewing and analysing the contents of music audio files, is now available. The main change in this release, and the reason for the major-version bump to 4.0, is the addition of a "boxes" layer used to annotate and export time-frequency regions. (Refer to https://www.sonicvisualiser.org/doc/reference/4.0/en/#boxes for a description of the boxes layer.) See the home page at http://sonicvisualiser.org for more information and downloads. Version 2.1 of Tony, a free, cross-platform, open source application for high quality pitch and note transcription from solo vocal recordings, is now available. This is what you might call a "consolidation release" - it is almost unchanged from 2.0 in terms of features, but it is updated to fix some compatibility issues that have arisen since 2.0 came out and to prepare the codebase for a future feature release. See the home page at https://www.sonicvisualiser.org/tony/ for more information and downloads. Version 1.0 of Sonic Lineup, a free, cross-platform, open source application for comparative simultaneous visualisation of multiple audio files containing versions of the same source material, is now available. See the home page at https://www.sonicvisualiser.org/sonic-lineup/ for more information and downloads. Chris |
From: Marc V. D. <mar...@gm...> - 2019-01-18 14:18:52
|
Hello, I'm a new subscriber so I apologize if this has been asked before. If I understand the plugins correctly, there is a difference between real-time features (computed in `process`) and non real-time features (computed in `getRemainingFeatures`). Is it somehow possible in SV to show to which group a feature (transform) belongs? Thanks in advance, Marc |
From: Chris C. <ca...@al...> - 2018-12-04 13:38:05
|
OK, we now have Sonic Visualiser v3.2-pre2: https://code.soundsoftware.ac.uk/projects/sonic-visualiser/files Just a few fixes since pre1, and no changes to translation strings. Hoping to make 3.2 at the end of this week, so if you have any showstopper bugs or major regressions to report, or translation updates to send in, please do so as soon as possible! Thanks, Chris |
From: Nimal R. <ni...@ee...> - 2018-11-25 04:03:02
|
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">v3.2-pre1 on Mac seems to work fine. The match plugin did not work correctly <br> with the previous version v3.1, but does work with this version.<br> <br> On 21/11/18 8:15 PM, Chris Cannam wrote:<br> </div> <blockquote type="cite" cite="mid:154...@we..."> <pre wrap=""> I've uploaded a set of test builds for Sonic Visualiser v3.2-pre1 here: <a class="moz-txt-link-freetext" href="https://code.soundsoftware.ac.uk/projects/sonic-visualiser/files">https://code.soundsoftware.ac.uk/projects/sonic-visualiser/files</a> Would appreciate any test feedback! Also there are a few new translation strings, if any translators are interested in taking a look. Changelog: <a class="moz-txt-link-freetext" href="https://code.soundsoftware.ac.uk/projects/sonic-visualiser/repository/entry/CHANGELOG">https://code.soundsoftware.ac.uk/projects/sonic-visualiser/repository/entry/CHANGELOG</a> There will be at least a week between now and v3.2, but I hope not too much longer than that. However, I am hoping in future to make releases at a slightly more active cadence than before - though they will still be led by what has actually changed rather than being regular time-spaced releases. Chris _______________________________________________ Sv1-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:Sv1...@li...">Sv1...@li...</a> <a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/sv1-devel">https://lists.sourceforge.net/lists/listinfo/sv1-devel</a> </pre> </blockquote> <p><br> </p> </body> </html> |
From: Chris C. <ca...@al...> - 2018-11-21 14:45:49
|
I've uploaded a set of test builds for Sonic Visualiser v3.2-pre1 here: https://code.soundsoftware.ac.uk/projects/sonic-visualiser/files Would appreciate any test feedback! Also there are a few new translation strings, if any translators are interested in taking a look. Changelog: https://code.soundsoftware.ac.uk/projects/sonic-visualiser/repository/entry/CHANGELOG There will be at least a week between now and v3.2, but I hope not too much longer than that. However, I am hoping in future to make releases at a slightly more active cadence than before - though they will still be led by what has actually changed rather than being regular time-spaced releases. Chris |
From: Bjoern H. <bjo...@gm...> - 2017-10-17 20:30:39
|
Hi all, sorry for this post - I couldn't register on the VAMP forum for some reason (after registration, page with blank body is returned, and the registration hasn't worked). Hope it's ok to ask the question this way. Firstly, thanks for making SV - it's a great tool! I'd like to use it for analysing mainly melody in monophonic music. Two questions: (1) Many of my recordings are a bit off pitch. Is there a quick way of interactively adjusting the overall pitch (say by 30 cent, but perhaps also by a few semitones in case of transposing instruments)? I know I can adjust concert A in the settings, but it would be very convenient to be able to visually adjust overall pitch on a session basis, rather than round-tripping with the settings. (2) The audio I'm looking at is mostly in musical scales - is it possible to overlay e.g. a major scale? I.e. a set of horizontal lines, representing a scale (e.g. F major)? It's of course possible to use the measurement tool, which is helpful, but it would be helpful if I could overlay a full scale. Many thanks! Bjoern |
From: Chris C. <ca...@al...> - 2017-09-22 15:13:23
|
On Mon, 18 Sep 2017, at 21:04, Ólafur Egilsson wrote: > Are the subrepositories every used on their own (in a different project?) Yep, SV uses a dozen or so subrepos almost all of which have an independent existence and are used in other projects. I'm also not keen on any solution that involves either moving everything into a monorepo or moving everything (including dependent libraries) to git. If moving an application repo to a different VCS means moving all its libraries as well, that's a problem I think. I have started on a github presence for SV, which you can find under its own organisation at https://github.com/sonic-visualiser. Currently this is only a mirror -- the canonical repo is the soundsoftware hg one, and that isn't going to change instantly. It somewhat experimentally uses a tool called Vext for managing external repos rather than using a specific version control system's subrepos/submodules. The short-term goal is to support CI builds through Travis and AppVeyor (that part is working) and to make this a better place to present issues, replacing both of the current trackers which are both rather obscure. After that we'll take stock again. > A developer interested in the project has to be incredibly dedicated if > he's to fight both Hg and Qt oddities at the same time. Maybe, but looked at from the other side, a developer who can meaningfully contribute to a project in C++ (complex, massive, pitfall-strewn language) using Qt (big framework) can surely cope with Mercurial! At least it's relatively simple compared to other version control systems. Chris |
From: Ólafur E. <ol...@gm...> - 2017-09-18 20:04:31
|
Regarding moving to Git and the hg sub repo problem: Are the subrepositories every used on their own (in a different project?) Could you dump the project onto github as a fresh one with no history and no subrepos and keep repository on code.soundsoftware.ac.uk locked for the archaeologist? It's not an ideal solution, but is it worth the effort to try to include the history and repos on github? A developer interested in the project has to be incredibly dedicated if he's to fight both Hg and Qt oddities at the same time. >I would like to get the repo (at the very least) mirrored on github, >primarily because at the moment the situation about where to file and >discuss issues is so unfriendly to new contributors. There are obstacles >to do with the heavy use SV makes of Mercurial subrepositories. I've >been looking into various options for dealing with that, but that work >s still pending. On Mon, Apr 10, 2017 at 10:09 AM, Chris Cannam <ca...@al... > wrote: > > On Sun, 9 Apr 2017, at 23:02, Ólafur Egilsson wrote: > > 1. Where is the best place to ask SV related (not vamp) dev questions? > > This list is not a bad place. It doesn't get much traffic at the moment, > but your questions should be noticed. > > > 2. Is there a build instructions somewhere (apart from INSTALL.txt). > > For Windows there is this wiki page: > https://code.soundsoftware.ac.uk/projects/sonic-visualiser/ > wiki/WindowsBuild30 > > I've also just updated the INSTALL file in the repo with a few more > notes. I'm intending to make an updated source tarball with more details > in this file than the 3.0.2 one had, so please do let me know what other > obstacles you have run into. > > > 3. Do you take code submissions from the community (for bugs and > > features)? > > Yes. > > > If so, do we have a formal/ideal protocol for such submissions > > (discussion, code style, how to submit, etc?) > > Discussion here or in a tracker issue (on SourceForge for example) is > good. Code style is primarily follow what exists already (camel case, > 4-char indentation, avoid tab characters, opening brace at end of > leading line etc). > > As for submissions, I'd say in the first instance send patches (here or > off-list). Then we can work out repo access. > > > (I do have a few lines of code submission related to playback which makes > > my life much easier when transcribing a solo. I think it might be useful > > for others). > > Sounds good. > > > 4. Has there been any discussion on moving to Git > > I would like to get the repo (at the very least) mirrored on github, > primarily because at the moment the situation about where to file and > discuss issues is so unfriendly to new contributors. There are obstacles > to do with the heavy use SV makes of Mercurial subrepositories. I've > been looking into various options for dealing with that, but that work > is still pending. > > > Chris > > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Sv1-devel mailing list > Sv1...@li... > https://lists.sourceforge.net/lists/listinfo/sv1-devel > |
From: \Thassilo Gadermaier\@O. <tha...@of...> - 2017-05-02 17:34:08
|
Dear all, so, did I get that right that Sonic Visualiser's Version for Windows does not have OSC capabilities? Because it does not/can not use liblo on Windows? Could someone be so kind to explain to me how to get OSC in SV on Windows? Or point me towards relevant information? I will attempt a build of the 3.0 Version on Windows in the next few days... if I can get OSC into that somehow, that'd be great. Thank you very much in advance, Thassilo |
From: Chris C. <ca...@al...> - 2017-04-10 09:09:33
|
On Sun, 9 Apr 2017, at 23:02, Ólafur Egilsson wrote: > 1. Where is the best place to ask SV related (not vamp) dev questions? This list is not a bad place. It doesn't get much traffic at the moment, but your questions should be noticed. > 2. Is there a build instructions somewhere (apart from INSTALL.txt). For Windows there is this wiki page: https://code.soundsoftware.ac.uk/projects/sonic-visualiser/wiki/WindowsBuild30 I've also just updated the INSTALL file in the repo with a few more notes. I'm intending to make an updated source tarball with more details in this file than the 3.0.2 one had, so please do let me know what other obstacles you have run into. > 3. Do you take code submissions from the community (for bugs and > features)? Yes. > If so, do we have a formal/ideal protocol for such submissions > (discussion, code style, how to submit, etc?) Discussion here or in a tracker issue (on SourceForge for example) is good. Code style is primarily follow what exists already (camel case, 4-char indentation, avoid tab characters, opening brace at end of leading line etc). As for submissions, I'd say in the first instance send patches (here or off-list). Then we can work out repo access. > (I do have a few lines of code submission related to playback which makes > my life much easier when transcribing a solo. I think it might be useful > for others). Sounds good. > 4. Has there been any discussion on moving to Git I would like to get the repo (at the very least) mirrored on github, primarily because at the moment the situation about where to file and discuss issues is so unfriendly to new contributors. There are obstacles to do with the heavy use SV makes of Mercurial subrepositories. I've been looking into various options for dealing with that, but that work is still pending. Chris |
From: Ólafur E. <ol...@gm...> - 2017-04-09 22:02:50
|
Hi, I have a few questions related to SV development. 1. Where is the best place to ask SV related (not vamp) dev questions? 2. Is there a build instructions somewhere (apart from INSTALL.txt). 3. Do you take code submissions from the community (for bugs and features)? If so, do we have a formal/ideal protocol for such submissions (discussion, code style, how to submit, etc?) (I do have a few lines of code submission related to playback which makes my life much easier when transcribing a solo. I think it might be useful for others). 4. Has there been any discussion on moving to Git (where all the cool kids are :) ) Thanks! |
From: Chris C. <ca...@al...> - 2017-03-03 12:16:35
|
See http://sonicvisualiser.org/new-in-v3.html for details about what's new in this release. Downloads from the usual page (http://sonicvisualiser.org/download.html). Chris |
From: Chris H. <c.a...@gm...> - 2016-09-01 10:04:54
|
Hello everyone, C4DM are working on a new major release of Sonic Visualiser and we would like to get some feedback from current users to guide development. We're particularly interested in identifying any pain points there might be in the installation process that might be problematic for new users and any issues in day to day user experience that could be improved to help people with their workflow. If you are a past, current or maybe a prospective user, we would be grateful if you would share your views with us by filling out the survey at the link below: https://goo.gl/forms/3RDGZHILopNecZiy2 The survey form will be open from now until the end of September. Regards Chris Harte |