Re: [PATCH] Spectrum views enhancement & small eq fixes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Depner a écrit :
> On Wed, 2008-02-27 at 01:05 +0100, Raphaël Doursenaud wrote:
>> [...]
>>
>> 1) Relabeled geq sliders with correct frequency.
>>
>
>     I have no idea what the "correct" frequencies are.  Neither what we
> have now nor what you have done matches any 31 band GEQ I've ever seen.
> I'll wait for Steve to chime in on that one ;-)  One of the reasons for
> not using 31.5 and 1k25 and 3k15, etc. was to save screen real estate.
> We really don't need to be exact anyway.  I'm more concerned about
> completely eating up every square mm of screen space.

Well "correct" might not be the word.

Uncommenting this around line 169 in process.c :
//printf("band %d = %fHz\n", i, centre);
provides the hyper precise floating point frequencies.

These are 1/3 octaves like on most professional geq in the market (See
for ex.
http://www.klarkteknik.com/images/content/products/product_shots/dn9331/dn9331-front.jpg).
This is what we should expect from a third octave geq, anything else is
just distracting.
This part of the patch doesn't seem critical for screen space. No
changes induced here for me with the default startup size.

>> 2) Correctly calculate tooltip frequency from new geq labels.
>>
>
>     This is more important than the labels.  I'd rather be exact with
> the tooltips since they don't use up space.

Granted! This part was the most fun.

>> 3) Correct spectrum view frequency labels.
>>
>
>     Same as above.

Here I can see a problem comparing 0.95.0 and CVS with band width and
font size that eats up space but it has nothing to do with my patch.
The displayed bands could (should?) be narrower.

>> 4) Accurate frequency display in spectrum view (fixes bug #1736245).
>>
>
>     Same as other above ;-)

I have not explained this one right (did this on a hurry before getting
some rest). In fact it now accurately displays the *level* of each band
where CVS and previous were practically unusable.
Say if you inject a pure sine signal @0dBFS it displays 0dBFS at the
frequency not ~-40 like it used to do.

>> 5) Same on hdeq display. As a side effect, removed rising/decaying display.
>> Plan to reintroduce it in a more flexible manner later.
>>
>
>     I'll wait for your more flexible patch to include any of this.  I
> don't think we want to remove a feature without providing a replacement.

Here the same applies to my new description ;)
I don't agree with you. Accurate level display is much more important to
me than time integration. Time integration is eye candy to me if not
controlled by the user (or at least know what the ballistic is).

What I plan to do is having separate "rise", "release" an "peak hold"
user controllable times. I just don't get the algorithm and math to do
this yet, let alone code. Any thoughts are welcome.

The "peak hold" time is another long standing issue in JAMin and will
require some work. Infinite peak hold is really bugging me.
For the sake of completeness I should do this on *all* metering. Better
polish up my skills or get a lot of help ;)

>> 6) Fix for "pen tool" measurement induced by new hdeq display.
>>
>> Accuracy of spectrum displays and measurements has been tested with the
>> excellent japa & jaaa as sound generators and display references.
>> This is my first C code ever. Please review, comment or commit ;)
>
>     I really like the locale fixes for decimal display in callbacks.c.
> I had no idea how to do that.  On looking through your patch I see that
> you have made changes to jam-ui.glade but also to interface.c.  That
> file should not ever be hand edited since it is generated by glade-2
> from the jam-ui.glade file.  I'm assuming you used glade-2 to modify the
> jam-ui.glade file.

The "locale fix" is for the geq tooltip calculations. The old code
didn't work well with 2 decimals. I'm running a french system with ','
as decimal point that exposed the issue very early to me. An english
user would never have seen this ;)

Yes, I do modified the glade file and generated interface.c from this.
That's why it's in the patch. Don't know if its safe to remove it. Is
the interface.c code generated at build time?
I've seen that glade3 switched to a new approach using libglade and no
more generated code, better be digging that way.

>     It's good to see more people getting interested in this.  If you'll
> address the interface.c issue and finish the decaying display work we
> can look at including this.

I think we can sort out the interface.c. We could reintegrate decaying
almost as it is today but we need to find why it eats up 20dBs. Since I
don't quite get how the actual code works I'll need some guidance.

>     Good job on your first C code.  What do you normally program in?

I didn't programmed at all these last years just some trivial scripting
stuff and the like. Used to do school projects in 68000 asm and later
some ugly java stuff. I just got the book from Kernighan & Richie and
learned what I needed. Now it's time for me to get to the real thing.
My main interest is audio not programming but I think it's a requirement
 these days with all the digital stuff around. Aiming at sound
engineering, I need to know what the tools I use are doing to my
precious signal and the level of trust I can put in these :)

Sorry for my not-as-good-as-i'd-like-it-to-be english. Hope you
understand...

Looking forward for more comments.

- --
Raphaël Doursenaud
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHxSCZaZKmNAdXaVURAq0BAKCsWk9elIMdo8dm4qyQ8uZpTRUaNQCg1DEp
4XtVZ52SzkqYdtKWvyAZMTk=
=tHEN
-----END PGP SIGNATURE-----

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jamin-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jamin-devel