| Newsgroups |
gmane.comp.audio.jamin.devel |
| Message-ID |
<[email protected]> |
On Wed Feb 27 9:34 , Raphaël Doursenaud sent:
>-----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.
It's fine with me. This doesn't match my hardware 31 band GEQ but it makes
sense to me as it is in the software one.
>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.
>
Making it narrower but still readable is not an easy task. There are limits
on what glade will let you do.
>>> 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.
>
Ah! Yes, that would be MUCH better ;-)
>>> 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.
>
I can add these to the preferences fairly easily. I'll take a look when I
get home this evening (I'm at work at the moment).
>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 ;)
>
I agree, a limited peak hold for the spectrum would be nice. I'm not sure if
that is what we want on the output and input meters though.
>>> 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.
>
I'll have to take a look at glade3. I haven't tried it yet.
>> 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...
>
Once again, your english is way better than my french ;-)
>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
---- Msg sent via CableONE.net MyMail - http://www.cableone.net
-------------------------------------------------------------------------
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