Hey hey hey! Look what I've got... I thought it important and complete enough to let you see where it is going. Check it out. Set up a fresh mudita24-1.0.3 folder and apply these patches so you can try them out. Niels, you could apply these to the tree right away, but there's a few more things that I need to do, so it's not completely done yet, but as of now, it is exactly like before, but will be better when done. See the AUTHORS file for my TODO details. Tim. On August 8, 2010 04:08:01 pm Niels Mayer wrote:

On August 9, 2010 08:53:21 pm Tim E. Real wrote: Sorry. That's not entirely true. We know the page and step increments beforehand. What was I thinking? I was trying to unify and simplify the new handlers. So I will try to remove that dependency, at least. But I still think a program separate from envy24control just might be necessary. ---- P.S. I studied the chip metering and code in detail. Now I understand what you said about it. Nice work on the scale conversion and display, Niels. I will try to align them with the slider scales better, by shrinking them a bit. Had some thoughts about the meters. Take the inputs as an example: The meters currently show pre-fader levels. I find that a bit odd. ie Adjusting the slider doesn't actually change the meter level. So by multiplying (er, subtracting?) the meter value by the slider attenuation value, we can have post-fader meter display. Sound good? Now, of course we need pre-fader display as well (we still need to know the unadjusted pre-fader level coming in) So I thought, either we have a pre/post fader toggle switch, or more interesting, we add meters to the DAC and ADC analog volume sections! But IIRC the routing has to be accounted for in that situation, or something like that. It's late. I'll remember tomorrow. Just toying with ideas. Probably the pre/post fader toggle switch is the best idea. Tim.

On Tue, Aug 10, 2010 at 1:14 AM, <fons(a)kokkinizita.net> wrote: The meters show the levels at the A/D&D/A's but also at other things that don't necessarily end up being routed to the analog I/O. See the "Peak" labels on http://nielsmayer.com/envy24control/envy24mixer-architecture.png ... That's: * 10 channels of hardware peak-levels of inputs (including an SPDIF pair). * 10 channels of hardware peak-level outputs (including an SPDIF pair). * 2 channels for the digital mixer output. So in reality (assuming reality==documentation== http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf ) the peak meters are part of the mixer. However, the peak meter information is most useful in the "Analog Volume" panel, but that would miss four-six channels + spdif-pair of outputs. As a stopgap, I put the dBFS value alongside each channel, since adding the full meters to this panel was a much larger and more radical change than my initial patches. A better design overall, IMHO would be to combine all 20 input and output faders feeding the digital-summer into a single panel. Instead of two faders per channel, just one fader and a panpot, which would normally be swung hard-left or hard-right, but should also have a detent or page-position at center mix. The panpot would also indicate inactive and set at center-mix when "L/R Gang" is selected. Each channel would have the numeric dbFS input value displayed as a "button", which when selected, expands a meter that fills the column vertically; and deselected, it goes back to being a text display of the peak levels. That mechanism of dynamically adding a meter per channel could also be used in the "Analog Volumes" section to optionally allow meter info to be displayed alongside each slider. They are "available" in that the output of the digital mixer is metered and that meter is always displayed in envy24control. If you want to see the resulting level of any particular channels' attenuation, "solo" it (by manually muting the other incoming channels) and observe the resulting levels under the "Digital Mixer" meters. (Actually, a "Channel Solo" option-menu would be a useful addition to the digital mixer GUI: "off", "solo left" "solo right" "solo center". -- Niels http://nielsmayer.com

On Tue, Aug 10, 2010 at 11:24 AM, Tim E. Real <termtech(a)rogers.com> wrote: This sounds like a good change. Prior, as the meters would not resize and I'd generally use them at their default or -t1 height, the truncation of the bottom of the 0 to -144db attenuator was done to allow better control over the rather coarse 1.5 dB attenuator increments at the top end. With the stretchable meters and sliders, when this level of control is needed, the window can be resized for it -- with kwin achieved with a flick of the window-frame towards screen edge. One other idea that wouldn't require shortening of the meters: fake the -48 to -60 range as "on" whenever -48.1 would be illuminated. Actually my comment //NPM: below, fudging value 51.0 instead of 48.164799306 = 20*log10(1/256) was wr/t making the bottom end of the meters do this a little to get the fit closer to what the scale widgets were drawing. Since you have control over the label-positions, you could probably get their positions and do the meters right w/o my fudging. I couldn't figure out a way to get at their positions w/o violating all sorts of APIs and making various wild assumptions. The simpler fudging hack employed seemed like a better bet. On Tue, Aug 10, 2010 at 8:09 PM, Tim E. Real <termtech(a)rogers.com> wrote: Yes, which is why meters should be present in the analog volume tab. Perhaps using the idea of the current dbFS label becoming a button, which when set, would display the associated channel's peak-meter. Or just splitting the ADC's into one metered/slidered panel,, and a different outputs panel with metering for 8 PCMs and their associated DAC controls. While it is true that "mudita24's" meters are perpetually in PFL (prefade listen) mode -- and this can be confusing to those expecting an analog mixer, the AFL (after-fade listen) metering doesn't necessarily make sense in this mixer. In this case, it doesn't convey new information. In an analog mixer, for example, it could indicate you've applied too much gain/eq even if the PFL's were in-range. An initial problem in viewing mudita24 as a "mixer" : if the "mute" is on, it doesn't display that, nor the contribution of the faders to the resulting stereo mix. However, this app is also, or perhaps mostly, to be used as an input leveling and metering utility alongside a real mixer and real metering solution in a DAW. The mixer might be used for it's traditional purpose as a "zero-latency monitoring" solution for performers, while relegating the final mix to ardour or qtractor -- both of which implement their own mixer and metering and work in the expected ways as a mixer. However mudita24/envy24control is unique in that it can set the levels in/out of the ADC's and DAC's as well as control the zero-latency monitoring mixer. So perhaps having proper emulation of PFL/AFL in this mixer may be overkill because it may not be the final production mixer people are concentrating on. Which makes displaying levels at the ADCs/DACs more important IMHO.... However, if dreaming along PFL/AFL lines, I prefer a different idea -- see native instruments traktor http://osx.iusethis.com/screenshot/osx/traktordjstudio3.png -- a "dual" meter per side, where the wide part of the meter is the input level as we show currently in "mudita24" ; for our use, the additional narrow outer band represents either the post-fader-level that you computed above, both for current levels and peak-hold levels, or it could display the overall digital mix level. (And get rid of the digital mix display on the LHS altogether, as it can be placed where needed on any meter). The outer band peaks would "auto-decay" while the input peaks remain constant. (Which would also give you both kinds of displays simultaneously). Not if you use the idea of a single fader and a panpot. Then the meter would be displaying the post-fader level, and the panpot would be determining how that is actually mapped to the individual channels. Saves a lot of space too -- one slider and one set of labels per channel. If you're volunteering to do the work, go for it!! :-) Although some minor improvements could improve usability, for any such wild UI changes, I'm wondering whether it wouldn't be better to create a libenvy24control and call it via Vala -- basically use most of the existing code but put up an "outer skin" in vala that'll serve as a flexible testbed for mixer experiments. Seems to me like this is the kind of application that needs to write itself, in terms of interpreting it's world -- the particular soundcard -- and dynamically generating whatever desired sets of user interfaces the user chooses/customizes (e.g. positioning of separate windows or single window with multiple positionable panels). I'd actually attach these to existing profiles so that each amixer-profile gets not only different hardware settings, but also whatever customized set of UI panels/sliders/meters the user come up with.-- so each profile gets saved along w/ a "script" that creates&configures the UI, inits the hardware, & attaches the appropriate callbacks, etc. Then you don't need to worry about splitting the analog outs panel, or anything... The user would set it up their way, and there's be a general initial catch-all default setup that would make all existing options accessible.. Although I think the latter would be total overkill, does anybody at least agree initial vala-based testbed idea sounds like an interesting option, or a totally stupid idea? The inner loop of the running application would still be the same C code... This is just a random thought... hopefully it won't derail an otherwise constructive thread, and good old "working C" is better than nuthin' code :-) -- Niels http://nielsmayer.com

On Wed, Aug 11, 2010 at 1:35 PM, <fons(a)kokkinizita.net> wrote: The only time I've seen EQ pre-frader is low-cut on a microphone preamp. I was using standard "mixing board" definitions of PFL and AFL per, http://www.mackie.com/support/faq/index.html ...... What are PFL and AFL? PFL and AFL are acronyms that describe a mixer's SOLO function. PFL stands for "Pre-Fader Listen" and allows the user to "solo" or audition the audio in mono at a point in the signal path before the channel fader. Perfect for a live sound situation where you need to dial in an instrument before bringing it into the mix. AFL stands for "After-Fader Listen" and allows the user to solo the channel at a point in the signal path after the channel fader. This is more commonly used for recording applications (the signal is also typically after the EQ and pan controls). The Main Output signal is not affected by PFL or AFL solo functions, though the Phones and Control Room outputs are. On all Mackie mixers, the solo function serves as the preferred way to set input levels. ...... Using a real mixer analogy, here the PFL levels are the current "peak" levels from the ice1712 architecture diagram I've posted; its values displayed in the meters present in "Monitor Inputs" and "Monitor PCMs" panels of mudita24. The AFL levels are available (as I mentioned earlier) only by "soloing" (aka muting all others) the channel for which the AFL's are being determined, and looking at the resulting levels on the digital mixer output. In this case, Tim E. Real's: "post-fader meter value = pre-fader meter dB value + slider dB value" is a trivial computation that could easily be displayed, and would be helpful to debug situations like "why can't i hear myself in the monitors" (because mute was on). Having a narrow second meter displaying the AFL levels (stereo), dynamically shadowing the PFL displayed, would be a helpful visualization of mixer function. Even more-so with an automatic fall-off of the side peak-level. In contrast, it would be less helpful, and potentially more confusing to have a modal interface that would require clicking a button to see the PFL's, if only AFL's displayed, or vice versa. Especially for people that might not be able to tell their AFLs from their PFLs and just want to see some dancing meters as sings of activity. I think that we are both in agreement that the AFL level meters are not strictly necessary. However, they may not be sufficient to provide a good visualization: having the AFL levels in the meters could help with understanding what's actually going on, hidden in the hardware. Similar to how useful it is here http://osx.iusethis.com/screenshot/osx/traktordjstudio3.png ... My suggestion would be similar, except that it would either show the computed AFL value, or it could be switched to display the overall stereo mix output. With its function made superfluous by that option, the standalone digital mix meter could go away. Such side-by-side metering functionality makes it easier to visualize the level of contribution a given input has to the overall mix level. The mute buttons are useful since there's no "solo" and one might want to set levels independently of whether a channel is monitored. The individual levels are useful because one might just want to use this thing as a mixer anyways, maybe because you don't have another one, and because, now that it's adequately metered, it actually performs the function of "midi-controlled outboard synth submix" quite nicely, and with better fidelity than an external mixer. -- Niels http://nielsmayer.com

On Thu, 2010-08-12 at 22:04 +0200, fons(a)kokkinizita.net wrote: Low-cut and EQs should be pre-fader and just the EQs + the fader should be switchable between pre-aux and no EQs + fader for aux, while low-cut always should be pre-aux too. Anything else is very unusual. - Ralf

On Thu, 2010-08-12 at 23:13 +0200, Ralf Mardorf wrote: It's for trim (gain), but for my mixer it's post-EQ and pre-fader. I was mistaken.

On Thu, 2010-08-12 at 23:32 +0200, Ralf Mardorf wrote: Sorry for another PS, but I guess meters vs listening bus, didn't test it, but this would be plausible.

On Thursday 12 August 2010 21:42:49 Niels Mayer wrote: I would really like to see a mixer that has the EQ post the fader. Sounds pretty dumb to me. That way the effect of the EQ would be influenced by the volume after the fader. Not good... And as most consoles have the insert (by default) pre fader, this would also put the inserts pre EQ... EQ after the initial gain is something totally different though;) Have fun, Arnold

On Fri, 2010-08-13 at 00:04 +0200, fons(a)kokkinizita.net wrote: Except that pre fade aux sends are typically tapped off post EQ by default, so (at least in an analogue console) you need the EQ pre fader to give a point that is post EQ but pre fader for feeding any aux sends switched to 'pre'. Also, you want the fader as close to the mix bus as you can get it so that the self noise of the channel strip is attenuated by the fader (and possibly the mute switch) rather then having the noise contribution from 48 sets of EQ always present on the output (even when only one or two channels are routed). Of course in a digital system you can do almost anything routing wise trivially. It seems to me that for the envy24 case we DONT want to pretend to be a mixer in the general sense of the term, what is wanted is far more like a set of input meters, control over the codecs and (possibly) a routing matrix, everything else is better handled further up the stack. Regards, Dan.

On Thu, Aug 12, 2010 at 11:45:39PM +0100, Dan Mills wrote: That is what I meant with 'good technical and practical reasons' (in the part of my post you did not quote). Ciao, -- FA There are three of them, and Alleline.

On August 12, 2010 07:57:10 pm Tim E. Real wrote: Sorry, am I breaking the rules? It is commented as a 'protected' C structure member. I think that means I'm not supposed to access it from an instance of GtkRange, rather I'm supposed to sub-class GtkRange. Tim.

On Sat, Aug 14, 2010 at 12:19:33AM -0700, Niels Mayer wrote: I've never seen a real fader that has any practical resolution below -80 dB: the next tick, 5mm or so down, is 'Off'. And most don't even go down that much. Right. For recording you'd better leave a margin of 15 dB or so. Increasing the recorded level (assuming your software records 24 bit or floats) is not going to improve your S/N ratio at all -it is determined by the preamp, not by the level on the 'tape'. I hope that nobody is going to use the soundcard's mixer to do a real mixdown - not if you have software like Ardour. The purpose of the soundcard's mixer is to provide monitoring while laying tracks, and function performed on a real mixer by the AUX busses. I never have seen a mixer that has solo on the AUX busses. For this kind of monitoring and this card you have two options: one stereo monitor, or two mono ones. For the first you'd want panpots. For the second you'd want two separte gains. The compromise is what I proposed: one gain control and just L and R buttons instead of full panning. This works well in both cases. Ciao, -- FA There are three of them, and Alleline.

On Sun, Aug 15, 2010 at 09:50:32AM +0100, Gordon JC Pearce wrote: I'm sure most people know that. And what is supposed to follow from this ? Most faders will be calibrated +10 or +15 dB at the top, so if the last tick is -80 dB, that means a range of 95 dB. More than that is pretty useless. The 144 dB range of the chip just reflects the fact that the gain is set by a 24-bit integer value, that's all. 1e8 in power, 1e4 in amplitude. - if you put in a 1V signal, a 0.01µV signal will result. 0.1 mv actually. Ciao, -- FA There are three of them, and Alleline.

... in summary... that's the reason why I thought the current 0 to -48dB ranges adequate, especially given that you can't hear -48dB unless you've got a really quiet computer/room ( :-( ) or a really loud soundsystem and a willingness to subject your ears to damaging volume levels just so you can perceive individual signal sources down at -48dB. Given the kind of mixer the ice1712's is -- -purposed mostly for zero-latency monitoring or creating a performer-headphone-mix -- focusing on better controllability of levels at the top end and not worrying about mixing-in below -48dB seemed like a good compromise. Tim's suggestion of going down to -60dB is a good one simply from the point of view of providing a comfortable emulation of the ranges seen in a real mixer. Faking the -60 to -48dB levels on the meters as a large "signal present" indicator -- that illuminates whenever the HW input level goes from 0 to 1.... (i.e. -48.1dB as indicated on current meters). Of course, a real mixer can also add gain rather than just attenuation, and doesn't force you to go to a different page to set the trim or microphone/preamp gain levels.... One idea is that the available remaining ADC gain on the inputs could actually be directly represented -- for the "Monitor Inputs" panel -- by dynamic markings on the sliders that can represent the available ADC gain. So for example, if the user sets the "Analog Volumes" back to 0dB gain on the ADC's, then switches back to "Monitor Inputs": the gain sliders "top end" will be dynamically reset allowing up to ~ +18 dB gain as provided by most implementations. Normally, the user would have a "custom" set of gain settings, including potentially consumer/pro settings, or device specific settings, and the "Monitor Inputs" sliders would allow a "delta" about the baseline settings of ADC gain set in "Analog Volumes." With such a setup, at least for "Monitor Inputs" one would not lose resolution as you decrease the gain in the digital mixer -- you could actually alter the gains on the ADC's towards attenuation as well. With all digital mixer sliders attenuating down to -60dB, the attenuation could be handled entirely by the gain-controllable ADC preamp (which goes down to ~ -63dB). All while leaving the digital attenuation level at 0.0dB. This combined approach to levels in "Monitor Inputs" -- that you're actually controlling ADC gain even though not in "Analog Volumes" panel, might eliminate the need to add meters to the "Analog Volumes" panel -- leave that panel as-is with the current labels showing accumulated peak levels. What to do with the extra space above the meter for the positive ADC gain on the sliders? -- similar to the "fake" area for -60 to -48dB, make a large area that turns red when the digital peak reads 0.0dB (instead of the dinky little red line at the top currently indicated). If it fits, perhaps even place the dBFS label into that area, and have it turn red by switching background color instead of foreground color as it does currently. -- Niels http://nielsmayer.com

On Sun, Aug 15, 2010 at 11:13:48AM -0700, Niels Mayer wrote: Two options: 1. Don't place them side by side, so they don't have to share the scale, or 2. Make both fixed size, and align them manually instead of relying on 'automatic' widget placement (which IMHO *never* produces anything worth looking at). Ciao, -- FA There are three of them, and Alleline.

On Tue, Aug 17, 2010 at 3:25 PM, Tim E. Real <termtech(a)rogers.com> wrote: So I applied the patches ( http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100817/… ) by doing 'cat mudita24-1.0.3-patches-2/*.diff | patch -p1 --backup' in the mudita-1.03 directory ( http://nielsmayer.com/envy24control/mudita24-1.0.3.tar.gz ) and it all looks great and works nicely. Seems much easier to control and snappier than 1.03, which seemed to slow things down with the sliders (or the ALSA level callbacks) versus 1.0 version. Now it's back to feeling quick again. The one regression I'm seeing versus the original 1.03 version: when you move the sliders up and down in "Monitor Inputs" or "Monitor PCMs", the dB labels change width going from -X.X to -XX.X (e.g. "-9.9" to "-10.0" changes width). This width change propagates through gtk so that if you do it on the left-most slider, all the other sliders will jostle-around horizontally as you sweep the attenuator downwards from +0.0 past -9.99 ... This is not happening on "Analog Volumes" -- I think I solved this issue in the original code by adding a space after the last decimal if the value > -10.0. Nope, I've been waiting on your changes and doing other things. I will test the Terratec DMX6fire next... One other regression I noted is that with the -n ( --no_scale_mark ) option leaves some extra space in the "Analog Volumes" panel, compared to the 1.03 version. I also notice that in 1.03, I forgot to add verbiage for the "-g" ( --channel_group_modulus )option to the --help output. Will test that along with the Terratec. Given how coarse the ADC/DAC/mixer controls are to begin with, is there a way to set the mouse scroll wheel to always increment/decrement the dB value by its minimum step-size (e.g. 1.5dB for attenuator, 0.5dB for DAC/ADC)? Last I checked, mouse-scroll incremented/decremented by two "clicks" -- whereas next/prev keys moved by one "click." Looks good. I'm pretty happy with the resolution and actual gain control provided by 0 to -48dB, but if you have something different in mind, go for it... I like the current level of granularity. -- Niels http://nielsmayer.com PS: Feature request -- have an "L/R gang" available on sets of inputs in the ADC/DAC section where the size of the set is the "-g" value, e.g. 2 by default for stereo. This would allow the option of changing volumes on all channels of a multichannel setup simultaneously. a "-g 4" would allow, for example two groups of four channels, and a "-g 8" would allow a single group of eight channels. Like the L/R Gang control on the mixer, this control would be optionally enabled.

On Tue, Aug 17, 2010 at 9:22 PM, Tim E. Real <termtech(a)rogers.com> wrote: This is far more complicated than it needs to be. I setup all the numeric labels to use monospace fonts, which by definition, are the same size for all characters. And I ensured that the number of characters in the numeric label at creation time remained the same as the number of characters that it could be set-to throughout the life of the application. That means ensuring all outputs are text-formatted to produce the same number of characters width, no matter what the input. The issue here would simply be done by padding "-9.9" as either "-9.90" or "-9.9 " such that when "-10.0" gets displayed, it's the same number of characters. Monospace labels will handle the rest. I really don't think explicit string geometry calculations should ever be needed in computing dynamic labels like this -- the widget is supposed to handle that at initialization time and size itself based on the skin/fonts/etc.... It's also distracting to use proportional spaced text for such dynamic numeric labels as they'd end up wobbling around, so even if it wasn't for the sizing issue, i'd still want to use monospace fonts and labels that don't change their width, for dynamic numeric labels. The issue of max width or min width isn't important. What's important is to prevent the widget from resizing in the first place. There's also significant inefficiency if labels are resizing unnecessarily, as there ends up being potential resize requests being passed up and down the widget hierarchy. DMX6Fire works fine. I think the control names are just different numbers.... The Dmx6fire has hardcoded names/labels in envy24control.c for particular inputs, instead of just being 1..N. I believe cards with no analog controls will have no "Analog Volumes" page. The not-fully-supported-by-alsa Edirol DA2496 ( http://www.soundonsound.com/sos/aug02/articles/edirolda2496.asp ) driver the person was using didn't correctly describe the codecs on his card, so it was as if there was no analog section or codecs to control. Note that some alsa-supported Envy24 cards are certainly missing analog controls -- those with only digital/ADAT ports such as the Event Electronics EZ8 ( www.event1.com/Support/Manuals/EZ8_MANUAL_V1_0.pdf ) and the Terratec EWS88D ( ftp://ftp.terratec.de/Audio/EWS/88D/Manual/EWS88D_Manual_GB.pdf ). For such cards, "Monitor Inputs" and "Monitor PCMs" would be useful with peak meters, and there'd be no "Analog Volume" panel, nor any possibility of combining the mixer and dac or adc controls onto the same page. Almost all the Envy24 cards I've seen have the same controls on the ADC's and DAC's so it's possible that my hardcoding would have worked in the majority of cases. I'm not sure about the M-Audio Audiophile 2496. http://www.soundonsound.com/sos/apr01/articles/soundcard.asp indicates the Audiophile2496 doesn't have the adjustable ADC gain, just pro/consumer, whereas the similar Terratec EWX2496 does: "One useful set of controls here, not found in the Audiophile, is a pair of faders to adjust Analog In Gain from the default 0dB setting in 0.5dB increments right up to +18dB." See the soundonsound article for pictures and detailed description of the windows control software for the two cards. It would be nice if someone with an M-Audio Audiophile 2496 could test this latest version of "mudita24" and send snapshots of what the "Analog Volumes" panel look like and whether it's correct. Even the latest Envy24-based designs seem to talk about +18dB controllable gain on the ADC's, for example: http://www.musonik.com/index.php/terrasoniq-ts-88.html . Seems like one major difference is that some cards have consumer/-10 pro/+4 level setttings available for the analog section (e.g. ftp://ftp.terratec.net/Audio/EWS/88MT/Manual/EWS88MT_Manual_GB.pdf ftp://ftp.terratec.net/Audio/EWX/2496/Manual/EWX2496_Manual_GB.pdf ). Yes, I just noticed this testing on the machine w/ the Dmx6fire and the regular mouse w/ scrollwheel. It would be very nice to have the scroll increment/decrement the same as the keyboard up/down. One additional problem noted regarding the scroll wheel. You can set focus by clicking in the labels/marks area of the slider, and key up/down/pageup/pagedown events are passed on to the scale widget correctly. Unfortunately, scroll-wheel events are not passed on even though the scale widget has the focus. You have to explicitly click in the scale widget in order for the scroll wheel to work. -- Niels http://nielsmayer.com

On Sat, Aug 21, 2010 at 1:37 AM, Tim E. Real <termtech(a)rogers.com> wrote: -0 (see below) Any chance option #1 can be the default? -1 If you must go this route (and ultimately, IMHO, the PFL/AFLfeature is not high on my desires list) consider a single level/slider and a panpot for L/R and have the meter (which is really a computed "virtual" value anyways) track the level slider. IMHO, the dual slider per channel configuration we have now is confusing and adds a lot of clutter. Consider getting rid of the -144dB option, and even the -48dB option, and focus on doing the -60dB option well. That's only 12dB of "too much space" that comes on or off at once and it's sort of like a large visual "signal present" indicator. Since this app comes up with a fixed size, what about, if the user stretches the app vertically, then it'll expose the longer sliders but leave the meters the same. That way, by default the app comes up looking ok, but if the user needs to test their dog's hearing or something by dialing in sounds under -48dB, they can stretch the app to reveal the longer sliders. Note that very few digital mixers out there worry about levels under 60dB, so if it adds much complexity (or potential for bugs) you might consider skipping it. See the snapshots of some digital mixers below for example. See above. Make it simple, at least for the user, and then for you as well. Also, it won't look as bad if you use the extra space below the meter for the panpot, and just use a single slider filling the entire vertical space of its container. Note a few screenshots of mixers with slider markings that stop at -60dB or less: http://www.musiciansbuy.com/mmMBCOM/images/Yamaha_mg206cusb.jpg (sliders stop at -45 ... last marking -40dB ... ) http://cachepe.zzounds.com/media/quality,85/brand,zzounds/makebigimage2-370… (Yamaha 01V 96 -- sliders go down to -50dB -- drool, esp in combination w/ a Terratec EWS88D or Event EZ8 ). http://www.gearslutz.com/board/attachments/remote-possibilities-acoustic-mu… ( Yamaha LS9 -- goes down to -60dB ) http://sneaker.fm/wp-content/uploads/2009/05/imagemackiemixer.jpg ( Mackie Onyx -- goes down to -60dB ) -- Niels http://nielsmayer.com

FYI, I'm setting this up: http://code.google.com/p/mudita24/ Those interested in becoming "Project committers" (Tim!) or "Project contributors" (people testing and making suggestions) please send me your google account or create one ( http://www.google.com/accounts/NewAccount ). Please add your suggestions, issues, bugs, etc: http://code.google.com/p/mudita24/issues/entry Niels http://nielsmayer.com ps: as it's easier to setup two projects at once, setting up mudita24 under http://code.google.com/projecthosting/ was a side-effect of my setting up a project for my first attempt at Vala programming: http://code.google.com/p/spekle/ pps: I am now absolutely sure that mudita24 would benefit significantly from a semi-automated translation/rewrite into Vala -- a programming language with concepts from this century!! It would be "easy" and a lot of suckage could be disappeared from the code over time, incrementally...

On Sat, Aug 21, 2010 at 1:24 PM, <fons(a)kokkinizita.net> wrote: Isn't that exactly what http://mudita24.googlecode.com already does, albeit with 0 to -48dB range on the mixer's faders, and meters that align with the scale on the faders? Niels http://nielsmayer.com

On August 10, 2010 10:06:17 am you wrote: I will shrink the meters slightly, simply to align better with the slider scales. Uh, if you don't mind, I actually want to increase the mixer sliders to around -60dB, instead of -48dB which I think may be a wee bit too high. The meters will only be as long as the -48dB mark, but the sliders will be longer, if it doesn't look too bad and there's enough room. Agreed. Good idea. Will try to allow that. Should be straight forward. I totally neglected the mouse wheel! (I use a trackball). Will investigate to make sure wheel works OK. I am aware of the issues when clicking on a slider, or moving it with the mouse. I'm working on it. Part of the problem with the sliders is that they operate with floating point. If you click on a slider it outputs a fractional value even if it's already on an integer value, especially when the slider is stretched. When you click on a slider, it sometimes goes back one fractional step, which may be enough to cause it to go back one integer step. I need to round() some of the values at several places in my code, but when I tried it I got a pre-c99 compiler warning about warning: incompatible implicit declaration of built-in function ‘round’. So I left it alone. Perhaps with your -lm fix this will go away, or else we can just modernize the build as 'c99 compatible'. With proper rounding some of these issues might go away. Good idea. I'm not sure what the correct course of action is. Let's see what the ALSA community recommends. I was only thinking of folks with old distros+gtk who might want to use mudita24. (Alas, that might not be possible.) That's why completely replacing envy24control with mudita24 worried me a bit. This has been an interesting summer project! Mudita24 is an important app, as you say, especially for those with expensive professional envy24-based gear. The meters, the markings, the feel. Good! Tim.