On Tue, Jun 21, 2011 at 12:05:19AM +0200, Julien Claassen wrote: Yes, although I prefer the way level is displayed in jack_meter, though it only seems to do one channel at a time and doesn't give a summary of average and max peaks the way ecasignalview does. Also, ecasignalview seems broken right now. :( Sounds more or less like what I was looking for, except not rt. I tried looking it up but didn't get much luck, so if you can send the link my way, I would greatly appreciate it. Best, S.M. --

Julien, I upgraded to 2.8.1 just yesterday, but I'm getting the same problem with ecasignalview: it stops updating after a just a few seconds. Jack_meter also displays the signal level horizontally but it uses the full width of the screen and has a scale in DB over the bar. Only drawback, as I said, it that it only handles one channel at a time and doesn't have the counters ecasignalview has. You can find jack_meter in, surprise, a package called jackmeter on Debian. Thanks for the code, I'll have a look at it and might even try to *big maybe) reuse some of it to create a multi-band version of jack_meter. We'll see, me and my big dreams... :) heers, S.M. On Tue, Jun 21, 2011 at 09:26:29AM +0200, Julien Claassen wrote: --

On Tue, Jun 21, 2011 at 09:53:34PM +0200, Julien Claassen wrote: BTW, songanalysis segfaults here. Can you confirm it runs on your Squeeze system? No, because the average peak level suddenly plummets to zero and resetting the counters means that they go back to zero and remain there. I'm not, because I was trying to keep the traffic in my mailbox to a minimum, but I probably should be. :) Cheers, S.M. --

Hello Massy1 Just ran my version and it works on my Squeeze. It told me the volume and even quite a good estimate of the tempo. I'm surprised. :-) Maybe I could pas you my compiled version of it. It only depends on system libraries, if I'm not much mistaken and so should run on your system without dependency troubles. Kind regards Julien -------- Music was my first love and it will be my last (John Miles) ======== FIND MY WEB-PROJECT AT: ======== http://ltsb.sourceforge.net the Linux TextBased Studio guide ======= AND MY PERSONAL PAGES AT: ======= http://www.juliencoder.de

On Tue, Jun 21, 2011 at 09:25:15AM +0200, Cedric Roux wrote: I thought about that. I know some C, but my knowledge of DSP programming using low-level languages is next to nonexistent. What I'm thinking of is nothing really fancy: besides a general meter, just measuring the amplitude in separate bands to gain a rough idea of where some peaks might be. I suppose it's just a matter of splitting up the signal into bands and measuring them individually, but I'm not sure how to do that. Maybe the code Julien has would elucidate this for me. Cheers, S.M. --

On Tue, Jun 21, 2011 at 09:50:11PM +0200, Julien Claassen wrote: That, and how would csound report in real-time? I know it has some fltk extensions to do something like that graphically, but I'm not sure whether it offers anything beyond a simple print-like function for the console. I thought of that: one could split up the frequency range using a bunch of chains with bandpass filters, but here again, how to measure and report in a timely, readable matter? I'd rather go the simplest route possible, since I don't need anything too fine-grained. Cheers, S.M. --

On Tue, Jun 21, 2011 at 05:48:13PM -0400, S. Massy wrote: Before you waste too much time on this: such metering is in general pretty useless, unless you are doing sound level monitoring to determine acoustic pollution levels to some official standard or something similar. And in that case you need very strictly specified hardware, filters, meter responses and postprocessing algorithms. For musical (mixing) purposes such a display may give you the illusion of providing some interesting info but it doesn't. Suppose you have a meter that displays the levels in say ten frequency bands. How would you use its output ? Try to make the levels equal, or fit them to some template ? If the purpose is to find which band is responsible for some peaks you want to reduce, forget it. Either things will be very clear and you can easily *hear* where the problem is, or you won't get any reliable output from your meter at all. The most useless of all would be a set of linearly spaced equal bandwidth filters as provided by a standard FFT. The least you need for musical use is perceptual filter set such as provided by japa. Note that japa (with its default resolution setting) computes more than 200 overlapping bands - way too much for any text based display. Ciao, -- FA

On Tue, Jun 21, 2011 at 06:37:31PM -0400, S. Massy wrote: The first question should be: what is the purpose of the spectral display ? In what way is it relevant ? How do you, or would you like to, act on what it shows you ? If you can answer that question, then the next step could be to determine what should be shown and how. If you are really limited to a text display, then something providing simple but useful information would be a better idea to spend some time on, e.g. a text output mode for jkmeter or ebumeter (both would be fairly easy). Ciao, -- FA

On Wed, Jun 22, 2011 at 02:23:24PM -0400, S. Massy wrote: Why would those matter ? Gate triggers usually are not selective on frequency. If they are they will be less precise in timing. Yes, yes, and yes. Ciao, -- FA

On Fri, Jun 24, 2011 at 02:32:37PM +0200, Philipp ??berbacher wrote: I'm facing more or less the same problems: little C++ experience, bewildered by the absence of comments. The X interface also seems to be pretty much integrated in the way the programme operates. Maybe it would be easier to just keep the DSP and JACK parts and reintegrate them in new code? Remember, this is coming from someone who is definitely no coding genius. :) Cheers, S.M.

Excerpts from Fons Adriaensen's message of 2011-06-24 23:33:56 +0200: You got me wrong there, I was looking for a way to add an additional GUI option to jkmeter as it is, Consequently I didn't look at the dsp files at all. The dsp files are indeed well commented. If I try to write a CLI GUI for jkmeter I'll choose the second approach which is to use only the dsp files. Regards, Philipp

On Wed, Jun 22, 2011 at 12:56:09AM +0200, Julien Claassen wrote: And then ? What are you going to do with e.g. a list of the ten highest bands ? Do you really think that doing some filtering on those frequencies is going to improve your mix or levels ? Ciao, -- FA

On Wed, Jun 22, 2011 at 11:33:41AM +0200, Julien Claassen wrote: Why would you adjust the snare if it sounds OK ? Who cares that it causes a peak at 410 Hz ? Unless you are mixing pinkish noise there will be spectral peaks. They are supposed to be there :-) And if the snare - or any other track - doesn't sound OK, then a spectral peak display is not going to tell you why if you can't find out without that. Forget the idea that a spectrum analyser is some magic instrument that can be used as a substitute for professional knowledge, experience, or your ears. Now if the point of the whole exercise is to reduce peak levels while preserving loudness, and if it's the snare that is causing the peak levels, that will be pretty obvious without a spectrum display. Even if the only 'visual' info you have is something like jack_meter. Changing the EQ a bit could be part of the solution, as could be limiting, or just lowering the level. The real peaks that can be reduced without modifying the sound are the short ones. Short in time means broad in the frequency domain. So they don't correspond to spectral peaks. The way to deal with them is using a fast lookahead limiter. Multiband compression can be used to raise the average level. What happens there is way too complex to be done manually by looking at a spectrum. It works by raising the level of the lower energy bands, not by assuming that the one with the highest level is the one causing clipping. You still need a peak limiter after the compressor. It also works because each band can have its own attack/release setting (faster for higher frequencies), which means that you can have more compression without it becoming too obvious. 'Points' meaning spectral peaks ? I'd suggest not trying to achieve anything in that way at all. Believe me, I've seen _much_ more people being fooled by a spectrum analyser than by their ears. Ciao, -- FA