Re: [LAD] Jack Transport: What happens when it reaches the end?

[Tim E. Real]

On 3/23/21 5:05 AM, Filipe Coelho wrote:

On 23/03/21 00:50, Tim E. Real wrote:
Hi list. Been curious about this question for some time but have not 
had time to rig a test for it.



If Jack Transport is rolling, at a frame near the end of its 32-bit 
unsigned limit,


 what happens when it reaches the end?


Does it roll over and continue from zero frame? Or does it stop?


It overflows the 32bit unsigned integer, continuing from zero.



Thanks. That makes sense I suppose.

Better to say if someone wants to detect it and stop they can,

 than to say they must start it again when they really wanted it to 
wrap around


 which might cause a glitch. In other words, out of the box it would 
suit say,


 a day-or-two-long loop security recorder without glitching, I imagine.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Jack Transport: What happens when it reaches the end?

[Tim E. Real]

Hi list. Been curious about this question for some time but have not had 
time to rig a test for it.



If Jack Transport is rolling, at a frame near the end of its 32-bit 
unsigned limit,


 what happens when it reaches the end?


Does it roll over and continue from zero frame? Or does it stop?


Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] A question to plugin host devs

[Tim E. Real]

On 12/20/20 11:59 AM, Fons Adriaensen wrote:

Hello all,

I wonder what are the pros and cons of using RTLD_NODELETE as
a flag to dlopen() and call dlclose () as soon as the required
symbols are loaded.

The alternative is to leave all shared object handles open until
the host terminates.

What are you doing in your plugin host (and why) ?

TIA,


A quick search of MusE code finds no usage of it out of

 21 matches on "RTLD_".

Only RTLD_NOW and/or RTLD_DEFAULT.


Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Audio plugins: Streamable audio ports?

[Tim E. Real]

On Saturday, July 9, 2016 6:07:37 PM EDT you wrote:
> Well, technically, VAMP doesn't really do audio-in=>audio-out plugins at
> all, but rather audio-in=>metadata out, so that doesn't really count.
> 
> but fundamentally in != out == analysis not realtime.

The term 'realtime' would be a bit muddy here since what I
 had in mind was that the streams could accommodate
 either 'live' or 'offline file' data, in a 'live realtime' mixing sense.

A stream info flag could indicate that the stream is in fact
 'stretchable' or not.

Thus both 'live' and 'file' input could be mixed agnositcally.
 
The goal would be to have, say LV2, support time-stretch plugins.
Imagine Rubberband as an LV2 stretch plugin.
The plugin can ask for more or less input data.

It seems this is the only type of processing that can't easily
 be supported by current plugin architectures, without building
 special embedded support into the application, since it requires
 pulling variable lengths of input data.

Thanks.
Tim.

> 
> On Sat, Jul 9, 2016 at 6:06 PM, Paul Davis 
> 
> wrote:
> > VAMP does this.
> > 
> > But such architectures are inherently not realtime.
> > 
> > On Sat, Jul 9, 2016 at 5:56 PM, Tim E. Real  wrote:
> >> Are there any plugin architectures that allow
> >> 
> >>  input data length different than the output length
> >>  such that the 'run' function can ask for more or less
> >>  input data, for example via some kind of stream?
> >> 
> >> Instead of passing 'run' a block of data, host would
> >> 
> >>  pass these streams so that 'run' can pull and push
> >>  whatever lengths it needs.
> >> 
> >> There would be compatibility information on each
> >> 
> >>  stream so that other streams could accommodate.
> >> 
> >> I thought I read of an LV2 extension or something...
> >> Or am I imagining something like Pulse?
> >> 
> >> Thanks.
> >> Tim.
> >> 

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Audio plugins: Streamable audio ports?

[Tim E. Real]

Are there any plugin architectures that allow
 input data length different than the output length 
 such that the 'run' function can ask for more or less 
 input data, for example via some kind of stream?
Instead of passing 'run' a block of data, host would 
 pass these streams so that 'run' can pull and push 
 whatever lengths it needs.
There would be compatibility information on each
 stream so that other streams could accommodate.

I thought I read of an LV2 extension or something...
Or am I imagining something like Pulse?

Thanks.
Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] GuitarSynth

[Tim E. Real]

On April 27, 2015 07:59:36 PM Ralf Mardorf wrote:
> On Fri, 24 Apr 2015 23:13:12 -0400, Tim E. Real wrote:
> >To reduce latency I even tried putting the guitar through a standard
> >time-domain pitch shifter (up one octave) and then into the detector.
> >Not bad, so so.

> Since "dead" strings aren't an option for me, this is something I'll
> test for monophonic converters, because they also suffer from
> accuracy and latency. I never tested this. Nice idea.

The purpose there was to shift the guitar up one octave before
 it goes into the polyphonic detector, so that I could reduce
 the number of FFT bins required and therefore reduce latency.

It worked better, kind of OK, but if you know standard 
 time-domain SOLA pitch shifters, they leave artifacts in the sound,
 so it's not an ideal solution.
A nice frequency-domain pitch shifter would be better - very little
 artifacts in the sound - but these shifters have large latency,
 so that cancels the purpose of this because time-domain 
 SOLA shifters have very little latency, but just the artifacts.


> JFTR, if I'm short of money, I boil "dead" guitar strings in water. As
> long as they only suffered from skin fat and particles of skin and they
> aren't worn out or suffer from oxidation, this refreshes the strings
> without a side effect.

Aw jeez, sad situation, buy a new set of strings, eh :-(
If you lived in my city I'd give you a pack!

Yeah I tried boiling them a few times long ago.
All that really seemed to do was bring out the rust even more!

I've always believed it's not so much the dirt or oxidation on the 
 string which is the problem:
That simply makes it appear like a slightly thicker string and thus
 the tuning changes slightly. Most of the dirt can be removed.
The real problem is the dozens of small 'cuts' along the string length
 that are accumulated over time from bending, or just playing, against
 metal frets. This produces horrible overtones. The single fundamental 
 frequency of a given fret position begins to 'split' into two or more 
 fundamental frequencies. Ugly.

Just a side 'note': A tip for players out there:
There is a tendency to think that one should adjust the pickup as close 
 as possible to the strings without touching them, for maximum output.
Seems reasonable right?
But no, don't do that. Because the strings then sit in a less linear
 portion of the magnetic field - on the 'down swing' they are attracted 
 much more to the pickup magnet than on the 'up swing'.
The result is mechanical nonlinear string motion, resulting in...
 split fundamental frequencies.
The effect is striking. You can hear it without even plugging the guitar in.
As you adjust the pickup ever higher, and pluck the strings, you can
 hear the horrible overtones from the frequency splitting. 
It's really gross sounding. So be careful.
Enjoy your day :-)

T.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [Source uploaded to GitHub] GuitarSynth

[Tim E. Real]

On April 26, 2015 09:10:30 AM Fons Adriaensen wrote:
> On Sat, Apr 25, 2015 at 08:35:56PM +0200, Albert Graef wrote:
> > > Question: I tried a demo product which did polyphony, with similar
> > > latency as my app, which claimed to have a full version with
> > > near-zero latency.
> > > 
> > > Is this actually possible?
> > 
> > Sounds like snake oil to me, but don't take my word for it.
> 
> Sound very unlikely. One problem with polyphonic pitch detection
> is two or more notes that share a number of harmonic frequencies
> and start at the same time. This will occur with many chords that
> contain simple intervals like octave and fifth.
> 
> It is possible to detect which harmonics are shared (they will
> have a different amplitude / phase profile) but this requires
> tracking them for some time and hence additional latency.
> 
> I suspect the same is even true for human perception. If we hear
> a perfect fifth chord we may have the impression to have detected
> that it consist of two notes immediately. But there are many
> examples of our brain playing tricks and 'backdating' the result
> of an observation which has actually taken more time than we
> think.
> 
> Real-time polyphonic pitch detection is still a research topic,
> just look at the publication dates of some of papers already
> mentioned. For a guitar it may be easier than the general case
> due to the restriced frequency range of each string and in
> general a clear attack of each note.
> 
> 
> Ciao,


OK Albert, I uploaded the source of my polyphonic guitar synth to:

https://github.com/terminator356/polyguitsynth

The latest version was written in Borland C++ Builder around 2000.

The source uses a few of my 'hidden continuous borderless mouse'
 controls which I discussed in another current LAD thread concerning 
 'user eXperience in Linux'.
You won't be able to actually build the source without those 
 controls' sources, which I did not upload :-(

However, I included the finished executable !
And... it *runs* under Wine !
:-)

(Gotta love Wine, the older the program, the better it is.)

Inspiration for the OP I hope.

Try it, both to see how the program works and to see how my 
 'hidden continuous borderless mouse' controls work.
(Press the mouse inside any of the edit boxes and then move the
 mouse, observe the mouse hides and the edit value rolls on and on...)

The source does include the actual DSP library I used.
It is the GNU2 licensed 'libdsp' from Philippe Strauss.

The program includes the ability to use the PC keyboard
 as a music keyboard, hence the map on the right.

[Fons:] Yeah, believe it or not it works best with *dead* guitar strings
 and the guitar's tone knob all the way down.
Don't want too many rich guitar string harmonics in there!
Given that, it works kinda OK.

Fons do you have any insight into wavelets and how they might
 be better for lower latency pitch detection than FFT?

Cheers.
Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] User eXperience in Linux Audio

[Tim E. Real]

On April 24, 2015 10:18:57 PM Tim E. Real wrote:
> 6: Now turn the mouse pointer back on.  Done.

Ehm, missed on of the best parts:
6:  Now return the mouse pointer to where it was when originally clicked.
7: Now turn the mouse pointer back on.  Done.

Although, realizing now that when using this 'mouse hiding' technique, 
 it doesn't really matter if we use crossing borders or centre-screen mouse.
As long as it returns to where it was when clicked (6:).

Hmm, realizing now that hidden cross-border might actually be simpler 
 and better than my hidden centre-screen thing:
 
My centre-screen technique is in fact limited to half-screen height maximum
 movement ie. DOES have screen borders that could be hit.
With hidden cross-border we roll for a full screen after another 
 after another...

T.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] GuitarSynth

[Tim E. Real]

On April 25, 2015 02:37:34 AM Albert Graef wrote:
> Hi Gerald,
> 
> cool project, I'm looking forward to give it a try. :)
> 
> On Thu, Apr 23, 2015 at 7:24 AM, Gerald  wrote:
> > definately, but that comes with the cost of extra hardware (pickup,
> > 6chan soundcard). I would build that into GuitarSynth if I had that gear.
> > But I'm also rather interested  multipitch out of one signal. It's just
> > more convenient too
> 
> Polyphonic pitch detection is much more involved and requires more advanced
> algorithms which are computationally intensive and thus hard to perform in
> real-time.
> 
> Commercial closed-source software like Melodyne can do this, at least in
> off-line processing. AFAICT, the latest Melodyne versions also do some
> real-time processing, but I haven't used Melodyne for some time and so I
> don't know how well that works.
> 
> I'm not sure either whether there are any good open-source codes for this
> available yet, maybe others can provide corresponding links. But here are
> some relevant answers from Stackoverflow and Stackexchange:
> 
> http://stackoverflow.com/questions/9613768/multiple-pitch-detection-fft-or-o
> ther/9626849#9626849
> 
> http://dsp.stackexchange.com/questions/11433/polyphonic-detection-mulit-pitc
> h-detection-chord-recognition
> 
> Also, here's an interesting recent DAFx paper on doing polyphonic pitch
> detection using autocorrelation:
> 
> http://www.dafx14.fau.de/papers/dafx14_sebastian_kraft_polyphonic_pitch_dete
> ctio.pdf
> 
> And then there's the work of Anssi Klapuri and others at Tampere University:
> 
> http://www.cs.tut.fi/~klap/iiro/
> 
> Also, there are algorithms for doing spectrum estimation such as filter
> diagonalization methods (FDM) and the classical Prony algorithm, but due to
> their complexity these probably aren't well-suited for real-time processing
> either (the Prony algorithm also suffers from numerical instabilities
> IIRC), and you still have to do the partitioning of the overtone series
> afterwards.
> 
> There's surely more, but that's what I could find with a quick Google
> search or remember from the top of my head.
> 
> Hope this helps,
> Albert

If it provides inspiration, I was doing this in the late 90's on Windows,
 in good ol' Borland C++ Builder.

I simply grabbed an open-source FFT library, and the rest was easy. 
Audio-to-midi polyphonic pitch converter.

It is a real riot! Super fun to try.

I was able to play polyphonic guitar chords and have it come out 
 as midi, for example piano. 
With velocity detection. And anti-retriggering.

There is one drawback. Latency.
For FFT to distinguish among notes  it needs a certain amount of 
 samples in a block. More samples per block for lower notes.
On guitar it was just sorta kinda usable, but fun.

To reduce latency I even tried putting the guitar through a standard 
 time-domain pitch shifter (up one octave) and then into the detector.
Not bad, so so.


Question: I tried a demo product which did polyphony, with similar 
 latency as my app, which claimed to have a full version with 
 near-zero latency.

Is this actually possible?

And with properly timed chord notes (not high notes sounding 
 before low notes ie lower latency for higher notes)?   


Related question:
Albert (and list), I am desperately searching for a pitch shifting 
 phase-vocoder audio plugin with lower latency than FFT.

I have read about wavelets for a long time. 
They are said to be better for this than FFT.
Hard to find real working examples except in commercial.

In PD, there is a wavelet pitch shifter (I think in PD extended)
 but it is *broken*
I emailed the list but got no reply except to contact the author,
 which I haven't done yet.

Are wavelets good for polyphonic pitch detection too?

Can anyone shed more light on them in this context?


Thanks for the links Albert, bookmarked and will check them out.
Tim.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] User eXperience in Linux Audio

[Tim E. Real]

On April 24, 2015 10:04:36 AM Thorsten Wilms wrote:
> On 23.04.2015 21:55, Len Ovens wrote:
> > That is why being able to adjust with both horizontal and vertical
> > movement is a plus. Take a look at zita-mu1 for an example. It is also
> > important to continue watching the position of the mouse when it leaves
> > the application window.
> 
> Yes. If the linear knob happens to be too close to a corner of the
> screen, both part of the vertical and the horizontal range may be out of
> screen, though. Changing direction forces you to spend attention instead
> of relying on autonomous movement, trained by repetition.
> 
> With pointer-based usage, you can allow the pointer to go beyond the
> edge. Some 3D application will have the pointer appear on the other
> side, as if it traveled through a portal. But with touch, you are out of
> luck, have to move the active area and allow the finger to be repositioned.
> 
> I think in many cases, horizontal sliders with labels and numerical
> values inside the slider area, are the better approach.

Hey guys.
For anyone wrestling with control design and the mouse pointer 
 being too close to the screen edge, there *IS* an attractive 
 technique you might not be aware of or forgot.

If you use a trackball, it is heaven!
Er... but if it's a touch pad, as mentioned ye may be lifting yer finger.

It involves hiding the mouse pointer and forcing it to do tricks.

1: Upon receiving a mousePress event, immediately *hide* the mouse pointer.

2: Now force the invisible mouse to the *centre* of the screen (to give the 
 mouse pointer plenty of 'headroom' before it would ever reach an edge).

3: Now upon reception of a mouseMove event, do something useful
 with the increment given by subtracting the new position from the
 centre-screen position. (Add the given increment to some object's position 
 or value, edit-box value etc.)

4: Now immediately *force* the mouse pointer back to the centre of the screen. 

5: Repeat 3: and 4: until mouseRelease event is received.

6: Now turn the mouse pointer back on.  Done.

This technique can be used for example with:
Linear-movement knobs and dials, and both vertical and horizontal sliders.
Canvases (2D and 3D!).
Edit boxes.

I've used this technique since the mid-90's on Windows, and now Linux.
It was harder to do in Windows than Linux.
I know a Windows 3D app of the type Thorsten mentioned.
I remember when that edge-crossing thing was added.
I shook my head, laughed out loud to my friend who paid money for that
 and was showing me the new version. So goofy that was, it seemed to me, 
 so I made this instead and added it to my own 3D apps!

I call it "Continuous borderless mouse movement" and my control class 
 names are like "RollEdit" RollCanvas" etc. because you can roll, roll, roll, 
 without ever lifting the mouse button and re-positioning the mouse.
Coupled with mouse acceleration and accelerator modifiers,
 you can roll a floating point edit box value with fine resolution, 
 or with a few more rolls plus acceleration, be into the thousands.
Great for example for 3D Z-axis zooming in/out quickly, continuously.

See examples in MusE, the continuous Pan and Zoom.

If I recall correctly, see also LMMS, and the audio editor Sweep.

I have yet to try, but believe the technique is good when you are forced 
 to deal with short sliders because you are not forced to map one 
 value-change per mouse-pixel movement, nor accept a mouse pointer 
 that goes way out of positional sync with the actual slider thumb 
 rectangle just to get good resolution/range stuffed into the short slider.

We discussed this in MusE recently, about our mixer, and I said if we 
 want short horizontal sliders stuffed into a thin vertical mixer strip,
 then it will be really crucial that we get these sliders right.
So I believed that this technique was really a (the only?) practical
 way to do it. Hide the mouse. 

What do you think?


About *circular* motion knobs and dials:
The awesome thing about them is, as someone mentioned, 
 if you need more resolution you simply move out to a higher radius.

But I've always believed the 'hidden borderless continuous mouse' 
 technique cannot be used here.
Because the user needs to know that they are drawing an arc, and what 
 radius they are at.
Whether that is done by showing the mouse, or hiding the mouse but 
 showing say a 'radius line', if you are near the screen edge you are stuck.
Maybe linear-motion knobs really are best used with this technique.

So I just realized now that the above mentioned border *crossing* 
 technique may help with these circular-motion knobs.
Let the mouse cross the border. Not a big problem for the user,
 they are mostly focused on the actual knob and its value.
They can move to (almost) any radius, and sure it's a little awkward
 near screen edges (like Asteroids - never did well on that one).
But hey what else can you do...

Now, a bit far-fetched but, what about showing a sort of temporary 
 

Re: [LAD] [Bulk] Re: Midi Beat Clock to BPM

[Tim E. Real]

On November 1, 2014 08:10:30 PM Clemens Ladisch wrote:
> hermann meyer wrote:
> > I try to fetch the bpm from the Midi Clock, and stumble over "jitter".
> > 
> > How do you usually fetch the bpm from Midi Clock, any pointer will be
> > welcome.
> 

> 

Interesting, thanks for that filter link! Could have used it before.

> MIDI clock is interesting, because deviations from the predicted clock
> frequency are either errors and must be suppressed, or are because of
> a change in tempo and must replace the old clock rate.
> Regards,
> Clemens

Hi Hermann.

Yeah, midi clock is a real pain, lots of jitter even on a 'quiet' channel,
 and gets worse on a 'busy' channel.

In MusE, I provide the user with several midi-clock-to-tempo filtering options.

My goal in MusE's case was to record a complete tempo graph for the whole 
 song, as it is playing from the external device, based on the midi clocks.

If the user expects that for a given song the external tempo will be only
 one value and never change, I provide very heavy multi-stage filtering 
 option: 4 stages each with 48-sample filters for a total of 192-sample 
 filter. Ultimately it produces a pretty flat tempo graph with only
 one, maybe two or three, tempo values - a very low data count.

If the user expects an occasional sudden 'step' in tempo, I provide
 another filter similar to the one I described, except it has a first-stage
 'large step pre-detector' to catch large steps better.

I also provide three other filters: 
Tiny: 2-stage x 4 samples = 8 samples =  1/8T note averaging.
Small: 3-stage 12/8/4 samples =24 samples = 1/4 note averaging.
Medium: 3-stage 28/12/8 samples = 48 samples = 1/2 note averaging.
 
And last, I provide a 'no filtering' option which records the tempos
 'as-is' with no filtering. I warn the user this may produce a very
 dense tempo graph with many small 'jittery' changes - a high data count.

Here's the thing: The tempo graph is used upon playback to govern
 the tempo of the song. If wave files are also involved in the playback,
 and midi clock was filtered, the playback synchronization of midi 
 with waves may drift due to the averaging of the filters.
So in this case, with wave files involved, I inform the user that the 
 best option here is the last one: 'no clock filtering' at all.
It produces a very dense 'verbose' tempo graph with lots of small
 jittery changes - BUT - it is the most accurate for playback and
 provides your best chance of exact synchronization - nothing was lost
 due to averaging.

HTH.
Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Buffer size changes. Was: Re: [LAU] Session management with NSM

[Tim E. Real]

Hi, I'd like to get some feedback here in LAD.

On September 3, 2014 07:44:55 PM Fons Adriaensen wrote:
>> On Wed, Sep 03, 2014 at 11:57:05AM -0700, J. Liles wrote:

> > (when I go from recording to mixing I usually change the JACK buffer
> > size... is NSM supposed to do this for me automatically? I don't see how
> > or why it would).

> RE switching buffer sizes, if your system works reliably with some
> size, there is no reason to use a larger one.

Did Paul say recently Jack's buffer size change system was never implemented?
Do I recall correctly that there is no way to switch?
Is the difficulty with internals, or conceptually? Or compatibility - how 
about: 
If any client in the graph doesn't implement the callback or the callback 
 returns false, simply don't switch buffer size. Zero compatibility issues?

*** Usage Scenario 1:
You start your favourite DAW with what seems a moderate Jack buffer size.
As you work, you start adding effects to various tracks.
But you go too far, adding one too many CPU intensive plugins, 
 say Phase Vocoders and so on, and now you have at best xruns, 
 at worst slowness/freezing.

Now you must shut the app down, shut Jack down, adjust Jack's buffer size, 
 restart Jack, restart the application.

In light of the Pulse-on-Jack-QJackCtl threads these steps may not be easy.

Pushing an app button to be able to quickly switch to a higher buffer size 
 would be cool !

*** Usage Scenario 2: 
J. Liles pretty much just said what I wanted to say:

During (but not limited to) recording, if you require to be able to monitor
 one or more live inputs, low latency small buffers are absolutely required.
When I say monitor, I mean WITH effects plugins, otherwise hardware 
 monitoring can be used.
Here the DAW is being used as BOTH a recorder and an effects unit.
I do it a lot and it's a PITA to have to keep restarting with a new size.

After recording, when live input is no longer needed, we no longer care
 about the buffer size and in fact DEMAND high latency higher buffer sizes.

The caveat here is that when switching to the 'live' low-latency mode,
 we often have to first turn off some CPU-hungry plugins (non-essential on 
 playback tracks) and save the song before switching, otherwise after the 
 switch the app is slow/locked/frozen.
Then after switching back to non-live high-latency mode, we can safely
 turn on those plugins again. 
So we absolutely need those higher buffer sizes too sometimes.

I've been dreaming of having such a dual 'mode' switch in MusE.
>From lazy to tight at the push of a button. 
Possible?

Thanks.
Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] More-OT: Pickups <-Fader mapping <- Ardour MIDI tracer

[Tim E. Real]

On August 24, 2014 10:23:28 PM Fons Adriaensen wrote:
> On Sun, Aug 24, 2014 at 07:19:11AM -0700, Len Ovens wrote:
> > Certaimly this is an extreme example and while a pickup is nice for
> > performing, I normally use a mic for this guitar for recording.
> 
> Still some piezo pickups can produce a really nice sound when used
> on a good instrument, in particular for the more jazzy genres.
> I've been amazed by this many times.

Good vibrations. Sorry for the OT steering...
My acoustic has one built in. Beautiful bright sound.
Piezos are so bright they usually require EQ-ing at the 
 pickup preamp stage. And a pickup preamp IS required.

Didn't know much about the mechanism 'till I studied  
 piezo/magnetic differences the other day on the 'net.
Now I know my acoustic a little better.
Piezo = bright(er than) single-coil sound + no magnetic hum. Yay.
I like those new piezo clamp-to-head tuners. Some show all strings at once.


Say, optical pickups, anyone?
http://willcoxguitars.com/custom-splash
The products use this:
http://lightwave-systems.com

I noticed that the strings seem to be covered by the optical block(s)
 some distance out from the bridge. 
This might explain why there doesn't seem to be any electric guitars
 shown, only bass and electro-acoustic, because we would need 
 close-to-the-bridge palm muting, although the ElectroAcoustic model 
 may be able to get a good sound, after all optical sound is completely 
 different and neither acoustic nor electric. 

Tim.

> 
> > For many people the best thing is a mic with a USB plug on it.
> 
> Sadly, yes.
> 
> Ciao,


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] Ardour MIDI tracer

[Tim E. Real]

On August 15, 2014 05:24:51 PM Len Ovens wrote:
> On Fri, 15 Aug 2014, Paul Davis wrote:
> > On Wed, Aug 13, 2014 at 10:16 PM, Len Ovens  wrote:
> >   Is it just me? Has anyone else looked at pitch bend events on the
> >   Ardour MIDI Tracer? Quick test:
> >   
> >   
> >- edit->Preferences->Control surfaces.
> >- select both enabled and feedback for generic MIDI.
> >- double click on it and select bcf2000 with mackie protocol
> >- open an external midi monitor (using qmidiroute here) and connect
> >   it to
> >   Ardours MIDI control out.
> >- also open Ardours MIDI tracer window and connect it to the same
> >   output.
> >(Now qmidiroute will be in decimal and MIDI Tracer is hex..)
> >- use the mouse to move the gain up and down on channel one with an
> >   audio track.
> >   =
> > 
> >  the trace shows MIDI messages. there are no 10 or 14 bit MIDI messages.
> > only "controllers" with 14 bit state. 14 bit state is sent as two
> > messages (when necessary). the tracer shows each individual message.
> 
> Pitch bend, which the mackie faders use, is specified in the MIDI standard
> and in the MCP spec as: Ex yy zz in one event. 

Correct. 
Pitch bend is the only truly 14-bit encapsulated message.
There is also one more, real time Song Position Pointer (F2, LSB, MSB).
I think it is 12-bit though.

One can use the pitch wheel for something other than pitch.
It is per-channel. You can have up to 16 14-bit pitch wheels 
 (or knobs/sliders/etc), per interface, each routed to whatever you want.

You would just have to reserve some channels, or even a whole interface.

Yay Mackie! And others doing this.

But do I wish MIDI had included at least one /more/ encapsulated 
 14-bit message per channel.

> WHere x = channel, yy = LSB
> (7 bits) and zz = MSB (7 bits). This is one event. This the way I send
> fader info to Ardour and It is also the way Ardour sends info back to me
> when I use a mouse to move a fader. Lets compare the output of the tracer
> with qmidiroute: (using fader5 as happens)
> 
> tracerdb  qmidiroute  midi
> ===
> Pitch Bend chn  5 1a  -0.5Ch  5, Pitch  4378 (111a)   e4 1a 42
> crt/alt/mousewheel down
> Pitch Bend chn  5 09  -0.5Ch  5, Pitch  4361 (1109)   e4 09 42
> Pitch Bend chn  5 79  -0.5Ch  5, Pitch  4345 (10f9)   e4 79 41
> There is no second midi event with the msb, this info is missing.
> 
> I am well aware that controllers are 7 bits in an event. The MIDI standard
> does double up some of them for 14 bit, 

I think you are referring to what I will call 
"14-bit aggregate 7-bit controllers", as opposed to 
"14-bit (N)RPN controllers".

> but I am not aware of anyone who
> uses them.

In my searches for products/software that use them I have seen a few. 
Good to plan for it anyway. I think ALSA can use it too - I think it is one 
 of the event types. 

> 
> Speaking of which... I was looking at the MIDI codes for some more upscale
> Control surfaces:
> Allen & Heath iLive control surfaces
> Yamaha CL series mixers
> 
> Both of these use NRPN (Non-Registered Parameter Number) for some of their
> messages. The A&H uses this because they have run out of controllers (I
> would guess) and still only get 7 bits for their faders. They use three
> events, the first one has the mixer channel (as well as the midi channel),
> the second has a code for what in the channel it controls (0x17 for fader)
> and the third is the data. 

Wow, so they just ate up 16,384 available 7-bit NRPN controllers.
That's an entire interface full.

Any 14-bit controllers at all on these AH models?

If so, do they have detailed info on exactly how it is sent, and options?
If not, do you have a way of reading what comes out of them (and when)?
NOT with ALSA sequencer or any of the 'snooper' apps I've seen. 
It must be either a true UART HW project or a low-level API for reading 
 the MIDI data. 

Does anyone out there know of a *true* sniffer application that handles 
 all 7-bit and 14-bit controller types and displays them conveniently 
 and correctly?

> Yamaha uses four events, the first two carrying
> the controller number (they have not bothered to group them the way A&H
> has) and the last two are MSB and then LSB. The wiki for NRPN says the
> controller number for the first two bytes should be 0x63 and 0x62,
> however, Yamaha has these listed backwards. As there are other typos in
> the same page, this may just be a typo too.

These are 14-bit NRPN controllers.

> I do not know if the Ardour midimap binding msg="byte byte byte" would
> handle this or not. I know Jack would consider this 4 events and probably
> not accept just the first status byte with 8 running status data bytes
> 

Re: [LAD] Open Source to be or not to be?

[Tim E. Real]

On July 1, 2014 08:09:22 AM Gordon JC Pearce wrote:
> On Tue, Jul 01, 2014 at 07:33:31AM +0200, hermann meyer wrote:
> > Regarding FaustLive, do you know that we (guitarix project) working
> > on a analog circuit simulation toolkit, which will generate faust
> > code from gSchem ( http://www.geda-project.org/ ) schematics?
> > Imagine a electronic circuit designer could create a plug schematic
> > and "hear" direct what a change from 1k resistor to 2k resistor will
> > sounds like, if such a toolkit be integrated in FaustLive.
> > 
> > Faust rocks!!

Nice! Now that got MY attention.

I suggested that a couple of years ago somewhere, possibly in Guitarix forums. 
The ability to go from schematic (to Faust) to actual real finished plugin 
 would be fun and educational in many cases. Other cases not so helpful 
 (say, digital delay best done with code).

Does this mean the gSchem family can use Faust/Guitarix tube models ? 

Interesting, thinking also toward the future to high-samplerate plugins 
 and hardware. Software Defined Radio for example.
Someone asked recently on Jack ML about high Jack sample rates (in MHz).

> Okay, so you get to hear what your simulation sounds like.  It won't sound
> even remotely like real hardware.  Circuit simulation only tells you how
> your circuit behaves in a simulator - it does not in any way resemble
> real-life results.

I think pretty good actually, in this case.
Faust and Guitarix have some nice sounding tubes.
Guitarix seems to have a solid foundation by using Faust.

The Guitarix Head's sound is awesome Hermann.

Have you ever thought of simulating the Head right down to
 adjustable power supply (Van Halen's Vari-AC Brown-Sound), 
 power supply ripple (simulated hum), and sag (commonly called 
 slow-gear effect)? 

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Just an information about the state of affairs - Re: forking (was Re: Aeolus)

[Tim E. Real]

On September 21, 2013 07:32:56 PM Fons Adriaensen wrote:
> On Sat, Sep 21, 2013 at 04:36:45PM +0300, Dan Muresan wrote:
> > M. Gavioli also sent me a private e-mail. He sounded like he was
> > worried about the community going after him (possibly legally I
> > guess). This is not a good outcome, regardless of intentions.
> 
> Indeed not. I'll take care of this. Maurizio Gavioli has nothing
> to fear, at least not from me. Nor do I consider him to be be
> 'simple minded' as was suggested, on the contrary.
> 
> Meanhwile I have removed all references to the mailing lists
> hosted by muse-sequencer, to the wiki (which resulted in a 404
> when I tried it yesterday), and some other dead links from my
> website.
> 
> For any enquiries, discussions, or whatever issues regarding
> Aeolus please just use the LAU or LAD mailing list which I read
> (almost) daily.
> 
> Ciao,

I thought you'd made a mistake meaning muse-score instead of 
 muse-sequencer, but...

http://www.muse-sequencer.org/index.php/Aeolus

Yikes! I had no idea that old 2006 page was there.
I could not figure out how to get to it from our pages.
But typing Aeolus into Google, lo and behold - there's /our/ page
 at the very top of the Google results. 
I've CC'd just to see what Robert and Joachim think.

(Hey Fons, check out the Aeolus logos that Joachim made at page bottom.)

Anyway, question:
How hard would it be to make Aeolus available as a plugin like DSSI, 
 LV2 or LinuxVST, or... WinVST?

Would that not solve all issues? Official code would always be up to date.
Maybe get the muse-score team to write the WinVST?
Ah, SDK NDAs, cost and so on is a problem? No muse-score WinVST support?
Hm. What can muse-score do? They need something to make noise in Win.
Still, I'm seeing hefty mods to your program out in the wild, maybe take 
 a look, pick and choose and merge some of them back?

Plugins are preferred over external apps - no added latency.
Also there's the ugly business of session managers and getting the
 whole multi-app setup to reload exactly as before.
When no plugin is available, one resorts to quickly hacking up an 
 embedded version of some cool app. It tends to grow from there.

MusE has never embedded Aeolus as a MESS plugin, but at one time 
 ZynSubFX was.

Fons you say Aeolus itself does not restore some settings (stops?).
But can a connected app restore them by sending the whole lot
 as midi controller values? Even better, if it's a plugin, the infrastructure 
 is already there (in MusE) to automatically restore settings, rather than 
 requiring some extra song data or controller values by the user for 
 said restoration.

Let us host Aeolus some day. Be our guest!

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] 14-bit CC / (N)RPN midi controllers question

[Tim E. Real]

On June 9, 2013 04:57:21 PM Tim Goetze wrote:
> [Paul Davis]
> 
> >On Sun, Jun 9, 2013 at 5:55 AM, Tim Goetze  wrote:
> >> Some MIDI devices do not employ 14-bit CCs or the NRPN mechanism.
> >> Access' Virus for example maps all CCs as single 7-bit values, and a
> >> forced 14-bit mode will break communication.
> >
> >this is absolutely *not* the proposal.
> 
> Thanks, that is good to know, and *sorry* about the noise!

No problem.
True, we're not talking about forcing anything, just intelligent
 detection and sending of all controller types.

But this shows one example where, as I say, I believe more input from 
 the user is required to properly determine what's coming in - 
 "do you want to accept 14-bit CC and (N)RPN controllers at all?".

MusE's definable instrument controllers have always allowed us to
 cover all uses for midi output. (We do have a Virus instrument definition.)
What I have done is added input instruments, so I'm trying to tie all this
 together for intelligent detection of input.
If the user *specifically* defines any of the normally reserved controllers 
 (data H/L, (N)RPN H/L) as 7-bit CC, then they will be used that way, and not 
 as their normally intended reserved usage as data or (N)RPN numbers.
Also if any 14-bit CCs are specifically defined, then both high and low
 CCs are interpreted together as 14-bit CCs, and *not* passed along as 
 normal 7-bit controllers. (Same for program banks.)
Together with the mentioned options ("Do you expect 'Verbose' separate 
 MSB/LSB or 'Unified' single controls?", etc.), I hope to cover all uses.

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] 14-bit CC / (N)RPN midi controllers question

[Tim E. Real]

On June 8, 2013 11:59:49 AM you wrote:
> On Thu, 2013-06-06 at 20:58 -0400, Tim E. Real wrote:
> [...]
> 
> > That regardless, I must make my own full encoding code anyway for
> >  our Jack midi driver, because Jack midi delivers separate events.
> > But that's totally understandable :)

I knew that comment might generate a response.

> I really think that, in Jack (and LV2), it should just be mandated that
> these (and all other multi-) events be shipped as one, 

Do you mean delivered as a single compact event?
That would be cool, but puts a burden on Jack to do encoding magic 
 that the driver may have missed, as is my case, so I wouldn't demand it. 
But if so, I would want all controller types and situations covered for me,
 no having to do my own silly encoding.
Still, I would hope maybe it would be fairly straight forward to let Jack 
 cover this, so that if the driver, lo and behold, did detect these events, 
 Jack could pass them along.
Not sure how, being a raw Jack midi buffer, maybe reserve some bits as flags...

Jack Universal Midi Encoder/Decoder API anyone? "Smartest of them all"?

But I can't stop thinking that all this 'guessing' by drivers (or Jack) 
 just can't work properly without input from the user:
Are we expecting separate coarse and fine adjustment input?
Or 'unified' single adjustments? If so, is LSB always sent? Always after MSB?
In fact, are we expecting 7 or 14 bits on this particular controller?

I find I can't get around those questions. Else if assumptions are made a 
 'unified' control may lead to value jumpiness. And...

About the mentioned 'timeout checking' method for automatic detection:
I can't help thinking that this would still not be adequate. 
If an overly-happy user has, and twiddles, both coarse and fine controls 
 at the same time, then we have interspersed MSB and LSB messages.

So as above, I think I'd need to ask the user if we're expecting separate 
 controls - that would be my 'Verbose' option I mentioned.

That's how JUMED could be a smart codec - accept some parameters?
He he...

> for the same
> reason that running status is forbidden: it's annoying and entirely
> pointless.

Hm, I do see a contrast. 
As in, why not also give us running status then. Is that what you mean?
I read some old Jack midi dev posts, it was agreed by most that running 
 status would just complicate things.
Still I wonder, wanting to know everything about what's coming in - 
 status or no status - could it be a clue as to the nature of the message? 
But that means only Jack's ALSA RAW driver could give it everything, right?
Another irony. What, I want encoding, but without it, I'd like running status?

(Psst: Is there a handy raw midi command or viewer that will show everything? 
 I tried cat dev/snd/* but it seems to only show input not output. Thanks.)


> Optimising for a 7-bit wire should be the driver's problem, if a wire is
> even involved...

Without a raw viewer or HW monitor I wonder exactly what is on my lines, 
 and is ALSA optimizing output. (Should, it's in the ALSA code and can be 
 turned off.) Got an o'scope though. That's always fun...

> 
> Some big fancy programs will have to deal with such things anyway, but
> the reality is that these events just aren't supported by most Jack/LV2
> apps.  I think it's a lot more likely they would be with a normalisation
> guarantee.
> 
> Some consider this best practice even over the wire (with the additional
> safety measure of nulling controllers at the end, but we could skip
> that): http://www.philrees.co.uk/nrpnq.htm

Naw Dave, I know you like talking midi :)
Good site, I like detail. But I didn't see mention of data MSB/LSB order
 and if LSB would be sent if its value didn't change.

Our app's instruments can be told to automatically send NULLs or not.

So anyway, I know all of this 14-bit stuff is shooting for some fairly obscure 
 support that may, or likely may not for many, be useful. I know some debate: 
Synths and volumes are supposed to interpolate anyway - but some don't.
And even if not, the only parameter that would likely ever need 14-bit would 
 be an oscillator frequency, being the most noticeable and irritating at 
 low-res for live performance. Thus Pitch Wheel should be all anyone needs.
Still, it'd be nice if we had at least one other high-res control on standby 
 if needed, say a high-Q filter frequency, which being almost an oscillator, 
 might be annoying at low-res in live performance. 

So it's there, but challenging, but I'd like to support it if I can.

Thanks.
Tim.

> 
> Cheers,
> 
> -dr
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] 14-bit CC / (N)RPN midi controllers question

[Tim E. Real]

On June 6, 2013 05:36:50 PM you wrote:






> On Thu, Jun 6, 2013 at 5:31 PM, Tim E. Real  wrote:
> 
> Lacking access to the full midi specs document, I don't know
>  if this question is addressed. I've looked at manuals for products
>  which support them and searched the web but I don't see a clear
>  answer to my question:
> 
> Is it safe to assume that a product or app which allows
>  binding a *single* HW or GUI control to either 14-bit CC
>  or 14-bit (N)RPN, would *always* send the value LSB, even if
>  the LSB did not change but the MSB did, when the control moves?
> 
> Do the midi specs address this?
> 
> 
> 
> > The specs do not address this. It is an error in the MIDI spec in my 
> > opinion, and I discussed it with someone from the MMA several years ago 
> > and 
> > they agreed with me. The spec should have ordered things differently OR 
> > required that LSB and MSB are always sent. They did not. The existing spec 
> > design is easy to implement in dedicated hardware but notably harder in 
> > software run on a general purpose machine because you need to pick some 
> > arbitrary timeout.
> > 
> > 
> > Every possible ordering/delivery sequence can be found in one or more 
> > devices.
> > 
> 

Amen to that.
You can imagine I'm having a heck of a time trying sort it all out.
Such a "comedy of errors" here. 

I didn't know my keyboard could send 7-bit RPNs until now. 
It sends low then high RPN param number, when everybody says
 it ought to be high then low. Yet no real harm it's only the param nums.

So I think "Yay I've got a true HW source to test with".
So I select an RPN parameter - 7-bits on this old KB and many other devices  - 
 and then operate the 'data' slider and I'm sitting in MusE going 
 "Why is ALSA seq giving me separate controller events?" 
Well, seems ALSA has no such 7-bit (N)RPN support, only 14-bit.
So I think, "Even if ALSA could take a 7-bit and deliver me a 14-bit with 
 the high value, it ain't working here!".
If so, I'm thinking it's because the data slider messages aren't full RPN 
 messages - the data slider simply sends data H.

A few ironies:

That it seems I must now manually encode these separated 7-bit RPN 
 ALSA seq events into our internal 'compact' RPN controller type.
Darn, maybe we ought to just go with ALSA RAW and DIY the whole thing.

That regardless, I must make my own full encoding code anyway for
 our Jack midi driver, because Jack midi delivers separate events. 
But that's totally understandable :) 

That I might pass received Jack midi events back through an ALSA encoder 
 and then back to MusE, yet I'd still need my own 7-bit RPN encoder.

That apart from dealing with single 14-bit controls, one must also be 
 prepared to support separate coarse and fine user controls. 
Meaning any order MSB or LSB, any time.
For that reason I am totally discounting anything to do with checking
 any 'time delay', which I have read about. I'll just try to work with values 
 as is. See my 'options' below.

That our internal 'compact' event types are ultimately just decoded 
 again before they are sent to any external midi port. But they are
 useful internally, for example for sending to soft synth control ports.

Luckily, we have some options.
We have output instruments, and I've just added input instruments.
Our instruments support user definition of special 'compact' internal 
 14-bit CC, and 7/14-bit RPN and NRPN controllers, and full 'Program'.
So when our driver receives midi it can now refer to the chosen input 
 instrument with some new options, for what kind of behaviour to expect 
 from  controllers, to help determine our internal 'compact' controller type.

The reason for the original question is that I was trying to decide
 between two or three new 14-bit instrument/controller options:

'Verbose': Either MSB or LSB are encoded anytime anywhere,
 together with their last LSB/MSB counterpart, initial zero. 
Good for separate coarse and fine controls. The midi ideal.
We get two different encoded 14-bit internal events, but hey,
 it makes sense here.

'Unified': Wait for LSB.
Good for a single 14-bit control - *if* it always sends LSB.

Possible third option *if* I should never expect an LSB:
'Verbose with LSB fill': Encode LSB anytime together with last MSB, 
 same as 'Verbose'. But encode MSB anytime with a filled LSB 
 (0 or 127 depending on MSB delta). 
This MSB delta check ensures a smoother transition.
Since we'll end up with two different encoded 14-bit events, we might as 
 well make the MSB encoded one have a smart LSB so that the next
 LSB will make it continue on the same upward 

[LAD] 14-bit CC / (N)RPN midi controllers question

[Tim E. Real]

Lacking access to the full midi specs document, I don't know 
 if this question is addressed. I've looked at manuals for products 
 which support them and searched the web but I don't see a clear
 answer to my question:
 
Is it safe to assume that a product or app which allows
 binding a *single* HW or GUI control to either 14-bit CC 
 or 14-bit (N)RPN, would *always* send the value LSB, even if 
 the LSB did not change but the MSB did, when the control moves?

Do the midi specs address this?
Or do you know of examples of such LSB optimizing-out?

Thanks.
Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixing audio: Noiseless volume changes

[Tim E. Real]

On March 18, 2013 11:58:48 PM Fons Adriaensen wrote:
> On Mon, Mar 18, 2013 at 07:43:32PM -0400, Tim E. Real wrote:
> > Ah, I may have answered my own question when I said:
> > "(One cannot simply wait for the current data value to be 'zero' because
> > 
> >  for example with a perfect square wave signal the 'current' value will
> >  never approach zero, hence the zero-crossing detection requirement.)"
> 
> The analog waveform always 'approaches' zero - it's bandlimited and hence
> continuous - it just may not happen at a sample point. In fact the chance
> that it happens exactly at a sample point is zero.
> 
> > So having no choice but to apply the volume at this cross point the
> > popping
> > 
> >  noise might still be heard. I guess that's what Fons meant by
> >  'reduced'...
> >  and what Paul meant by... bogus. Right?
> 
> Imagine a signal slowly passing through zero, e.g. a low frequency
> sine wave. If you switch gain at an arbitatry point there will be
> a 'step', having a 1/F spectrum (just like a square wave). If you
> switch at a zero crossing there will be 'sharp corner', and this
> has a 1/(F^2) spectrum (like a triangular wave). So instead of a
> sharp click there will be something more like a 'thump'. The only
> real solution is to never switch the gain, but change it smoothly.
> 
> Caio,

Cool. Got it. And the response to James. Thanks very much. 
It is here at the mixing stage that I want to limit control motions.
All our controller graphs are sample-accurate and it's possible to
 deliberately draw sudden changes, also it's possible to suddenly
 change a GUI slider or knob's position.

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixing audio: Noiseless volume changes

[Tim E. Real]

On March 18, 2013 07:04:52 PM Tim E. Real wrote:

On March 18, 2013 06:47:16 PM you wrote:




On Mon, Mar 18, 2013 at 5:50 PM, Tim E. Real  wrote:

Hi again. Looking for any advice, tips, tricks, anecdotes etc.

I want to eliminate or reduce 'zipper' noise on volume changes.
So I'm looking at two techniques:
Zero-crossing / zero-value signal detection, and slew-rate limiting.
Code is almost done, almost ready to start testing each technique.
Each technique has some advantages and disadvantages.

If I use a slew-rate limiter, I figure for a sudden volume factor change
 from 0.0 to 1.0, if I limit the slew rate to say 0.01 per sample then after
 100 samples the ramp will be done.
But even with a fine ramp, this still might introduce artifacts in the audio.


You cannot avoid artifacts in the audio. The only question is what is the 
nature of the artifacts.  

 
If I use a zero-crossing/zero-value detector and apply volume changes


Zero crossing stuff is a completely bogus idea that needs to be eliminated from 
the lexicon of audio software. You will not be accomplishing anything trying 
to use such a technique, other than introduce even more artifacts (and rather 
horrendous ones at that). Even zero-valued samples are not particularly useful 
- keep in mind that what defines transducer (read: speaker) behaviour is power, 
not instantaneous volume.  

Just use sensibly short ramped changes. For the record, Ardour uses 64 or a 
JACK period size, whichever is, hmm, larger or smaller, can't recall.

--p


Wow, surprising answer. 
Can you elaborate a wee bit on the bogus point? What worse artifacts?
Popping noise will be heard if sudden volume change is applied while
 the signal data value is currently non-zero.
Is it not better to apply (register) the changes during zero or near-zero
 signal data values?

After all, some electronic systems employ it: 
http://en.wikipedia.org/wiki/Zero_crossing
http://electronicdesign.com/analog/digital-volume-control-eliminates-zipper-
noise

Thanks.
Tim.


Ah, I may have answered my own question when I said:
"(One cannot simply wait for the current data value to be 'zero' because
 for example with a perfect square wave signal the 'current' value will never 
 approach zero, hence the zero-crossing detection requirement.)"

Yeah, I was worried about that bit: 
That's not just an exception. With all kinds of waves not just square, many 
 times the current value may not approach zero even if it did 'cross' over.
So having no choice but to apply the volume at this cross point the popping
 noise might still be heard. I guess that's what Fons meant by 'reduced'...
 and what Paul meant by... bogus. Right?

Thanks.
Tim.___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixing audio: Noiseless volume changes

[Tim E. Real]

On March 18, 2013 06:47:16 PM you wrote:




On Mon, Mar 18, 2013 at 5:50 PM, Tim E. Real  wrote:

Hi again. Looking for any advice, tips, tricks, anecdotes etc.

I want to eliminate or reduce 'zipper' noise on volume changes.
So I'm looking at two techniques:
Zero-crossing / zero-value signal detection, and slew-rate limiting.
Code is almost done, almost ready to start testing each technique.
Each technique has some advantages and disadvantages.

If I use a slew-rate limiter, I figure for a sudden volume factor change
 from 0.0 to 1.0, if I limit the slew rate to say 0.01 per sample then after
 100 samples the ramp will be done.
But even with a fine ramp, this still might introduce artifacts in the audio.


You cannot avoid artifacts in the audio. The only question is what is the 
nature of the artifacts.  

 
If I use a zero-crossing/zero-value detector and apply volume changes


Zero crossing stuff is a completely bogus idea that needs to be eliminated from 
the lexicon of audio software. You will not be accomplishing anything trying 
to use such a technique, other than introduce even more artifacts (and rather 
horrendous ones at that). Even zero-valued samples are not particularly useful 
- keep in mind that what defines transducer (read: speaker) behaviour is power, 
not instantaneous volume.  

Just use sensibly short ramped changes. For the record, Ardour uses 64 or a 
JACK period size, whichever is, hmm, larger or smaller, can't recall.

--p


Wow, surprising answer. 
Can you elaborate a wee bit on the bogus point? What worse artifacts?
Popping noise will be heard if sudden volume change is applied while
 the signal data value is currently non-zero.
Is it not better to apply (register) the changes during zero or near-zero
 signal data values?

After all, some electronic systems employ it: 
http://en.wikipedia.org/wiki/Zero_crossing
http://electronicdesign.com/analog/digital-volume-control-eliminates-zipper-
noise

Thanks.
Tim.___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Mixing audio: Noiseless volume changes

[Tim E. Real]

Hi again. Looking for any advice, tips, tricks, anecdotes etc.

I want to eliminate or reduce 'zipper' noise on volume changes.
So I'm looking at two techniques:
Zero-crossing / zero-value signal detection, and slew-rate limiting.
Code is almost done, almost ready to start testing each technique.
Each technique has some advantages and disadvantages.

If I use a slew-rate limiter, I figure for a sudden volume factor change 
 from 0.0 to 1.0, if I limit the slew rate to say 0.01 per sample then after 
 100 samples the ramp will be done.
But even with a fine ramp, this still might introduce artifacts in the audio.

If I use a zero-crossing/zero-value detector and apply volume changes 
 only at these safe points, that's a much more desirable 'perfect' system.
But I stuck a time limit on waiting for a zero-cross because it's possible 
 the signal might have a high DC offset, or contain VLF < 20Hz.
(One cannot simply wait for the current data value to be 'zero' because
 for example with a perfect square wave signal the 'current' value will never 
 approach zero, hence the zero-crossing detection requirement.)

At some point waiting for a zero-cross, a ramp would have already finished 
 and it may have been better to use that ramp instead.
Conversely, a zero-cross might happen sooner than a ramp could finish,
 and we definitely want to use that zero-cross here instead of the ramp.

So it means I either have to give the user a choice of the two techniques, 
 or try to automatically switch between them - which ever one occurs first,
 the ramp finishing or the zero-cross, use it.
But it means I have to keep two audio buffers - one for applying the ramp
 as the samples are processed, and one for waiting until zero-cross happens -
 and which ever one "finishes the race" first, that buffer "gets the nod".

The zero-crossing technique has some interesting implications.
For a stereo signal each channel's zero-cross will happen at different times.
So I'm trying to imagine what that's going to sound like where the volume
 changes happen at slightly different times, if it will be noticeable, even 
 though that is far better than 'zipper' noise.
Also I'm trying to imagine how track cross-fading support would deal 
 with zero-crossing - if it is better to use ramps in that case.

What do you think?

Thanks.
Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixing audio: Implementing pan and balance

[Tim E. Real]

On March 14, 2013 11:42:41 AM you wrote:
> On 03/12/2013 08:08 PM, Tim E. Real wrote:
> > But having said that, yes I'm wondering about a true 'stereo pan' feature.
> > How would such a feature work?
> 
> there is no one true stereo pan.
> 
> a pan law for intensity stereo (i.e. a panned image or an XY coincident
> microphone pair) would increase one channel and decrease another such
> that the total energy remains constant. a cosine/sine law is usually
> used, because
> 
> cos^2 + sin^2 = 1

OK got it thanks, was wondering what curves to use.
Any easy way to obtain some of the other laws, like 4.5dB?

> 
> ardour3 attempts to do this, by allowing you to reduce the width (by
> introducing crosstalk), and then letting you move the compressed image
> left or right. sort of works, but only for pan-potted stuff.
> 
> a pan law for run-time stereo (i.e. spaced omnis) would have to use
> delays, leaving the original level intact.
> 
> the ardour3 panner gets this type of signal horribly wrong, because you
> _never_ want to introduce crosstalk in spaced omnis - instant
> comb-filtering hell.
> 
> for stereo techniques that incorporate both run-time and intensity, such
> as ORTF, NOS, EBS, you-name-it, you need different amounts of gain
> change _and_ delay.
> 
> that's why nobody wants to use a ready-made stereo balance control - it
> is almost guaranteed to do the wrong thing for the source material at hand.
> 
> best,
> 
> 
> jörn

I know what you guys mean about potentially disastrous results panning 
 stereo input material having already complex relationships between its 
 two channels. Probably no-one should try to pan that type of material 
 unless they know what they're doing or have a sophisticated panner. 
Try to take care of that stuff earlier on in the chain, hopefully where the 
 sources are mono, even then the relationship could be complex.

But my own use case is a much simpler desire: To position or blend two 
 completely independent L and R sources - I double track my guitars. 
So two resulting mono 'wave' tracks having mono strips both fed into 
 a stereo strip where a dual-instance shared-gui-controls mono distortion
 is placed in its plugin rack. The shared plugin controls are a major 
 convenience of the stereo strip - I want the same sound from each guitar.
Currently there's no way for me to adjust the positions of what comes out 
 of this stereo strip - which is still completely independent L/R material 
 stuck all they way to the left and right.

So I cleaned up some code, trashed some old stuff, readied the system
 for easily adding any new controllers, such as new panning controls.
After that, factor them into the mixing code. Then have some GUI fun.

So far so good, useful fixes even before proceeding, but...  should I? 

Question:
A3's modular panners make a lot of sense in light of these discussions -
 let the user pick the "right tool for the right job". 
Is there a suite of plugins, say LADSPA, that could do this for me?
Each plugin would arrange the four factors in different ways, like one
 would arrange it as basic four faders, another would have one fader and 
 two panners and balance, another maybe two faders and two panners,
 maybe add some sophistication like the delays and crossovers mentioned. 
Basically entire 'strips' all on their own. (Ironically MusE displays control 
 outputs as meters in our generic GUIs, so if 'level' outputs were provided, 
 these GUIs really would be cool complete alternative advanced 'strips'.)

Couldn't find any. If none exist, anyone up to the task? Useful for all DAW?

Thanks.
Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixing audio: Implementing pan and balance

[Tim E. Real]

On March 12, 2013 09:22:39 PM Fons Adriaensen wrote:
> On Tue, Mar 12, 2013 at 04:24:49PM -0400, Tim E. Real wrote:
> > Interesting about the crossover bit.
> > Wow, I considered adding selectable pan laws but didn't realize
> > crossovers.
> 
> The rationale behind this is that at LF the L and R signals will add more
> or less in phase, while at HF the phases are random and what gets added is
> the power.
> 
> The mixer app I've been developing has only Ambisonic panning. If you
> want stereo, you use a first order horizontal only bus (3 channels),
> use the -45 to +45 degrees range of the panner, and decode to stereo
> in the master strip. Then it's that decoder that determines the relative
> center gain of the panner, and it's no problem to make it frequency
> dependent so you get -6 dB at LF and -3 dB at HF.
> 
> > I will look at having separate pan controls for each channel on one strip,
> > 
> >  as I'm reminded from talking to Paul that Ardour has this :)
> 
> A2 had this, but no way to change the relative gains of L and R.
> The full matrix from L,R to L',R' has four coefficients. One of
> those factors out as channel gain, so three remain. So a really
> universal stereo -> stereo 'panner' must have three independent
> controls.

Yeah, you're right. Four factors for a two channel strip. 
Either two faders and two pans, or one fader two pans and a balance.

Took me a while of staring at the 'Panning' picture on Ardour's features 
 page. There's the missing link -  the relative gain you mentioned - which 
 is the slider between the L and R icons. 
If I may refer to that little slider as 'balance'...

I can see how the new panner would work for one channel strips too.

Very nice stuff, love the new usage of colours, shading and gradients.

Hey Paul, Robert made an Ardour stylesheet for MusE. It's... uncanny!

Tim.

> 
> Ciao,
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixing audio: Implementing pan and balance

[Tim E. Real]

On March 12, 2013 04:28:19 PM you wrote:




On Tue, Mar 12, 2013 at 4:24 PM, Tim E. Real  wrote:


I will look at having separate pan controls for each channel on one strip,
 as I'm reminded from talking to Paul that Ardour has this :)


not anymore ...



Oh wow, haven't tried A3 yet.

[Looks at, drools actually, the mixer on the new Ardour features web page...]

I see.
Now that's a smart looking mixer.

Tim.___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixing audio: Implementing pan and balance

[Tim E. Real]

On March 12, 2013 09:56:15 AM Fons Adriaensen wrote:
> On Tue, Mar 12, 2013 at 01:23:02AM -0400, Tim E. Real wrote:
> > I noticed our app uses this pan formula:
> > vol_L = volume * (1.0 - pan);
> > vol_R = volume * (1.0 + pan);
> > 
> >  where volume is the fader value, pan is the pan knob value
> >  which ranges between -1.0 and 1.0, and vol_L and vol_R are the
> >  factors to be applied to the data when sending a mono signal
> >  to a stereo bus.
> > 
> > When pan is center, 100% of the signal is sent to L and R.
> > At pan extremities, the signal is boosted by 3dB.
> 
> 6 dB actually.

Sorry I thought the wiki pages were referring to power so
 I expressed it as power.

> 
> > But according to [1], we should be using a Pan Law [2],
> > 
> >  where pan center is around 3dB to 6dB down and pan
> >  extremities is full signal.
> 
> There are two independent issues involved here:
> 
> 1. The attenuation at the center w.r.t. to extreme L and R.
> 2. Whether the center or the extremes should be 0 dB.
> 
> (2) is very much a matter of taste and of virtually no practical
> consequence : you will adjust the fader (channel gain) to get
> the right balance anyway.
> 
> Regarding (1), if you take psycho-acoustics into account you'd
> want -6 dB at the center for low frequencies and -3 dB for high
> frequencies, with a gentle crossover at around 500 Hz or so.
> So the SSL compromise of -4.5 dB makes sense.
> Note that unless you use the panner to move a sound around
> during a mix, all of this hardly matters: you will adjust
> the balance anyway and compensate for whatever the panner
> is doing.
> 
> Returning to (2): for a panner (mono -> stereo) I'd prefer
> 0 dB at L and R. For a balance control (stereo -> stereo)
> I'd prefer 0 dB at the center position.

OK thanks. Makes sense to me. That obeys the pan rules.

Interesting about the crossover bit. 
Wow, I considered adding selectable pan laws but didn't realize crossovers. 

I will look at having separate pan controls for each channel on one strip, 
 as I'm reminded from talking to Paul that Ardour has this :)

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixing audio: Implementing pan and balance

[Tim E. Real]

On March 12, 2013 03:13:44 PM you wrote:




On Tue, Mar 12, 2013 at 3:08 PM, Tim E. Real  wrote:

lance, but slightly different levels, but not a true 'stereo pan'.

But having said that, yes I'm wondering about a true 'stereo pan' feature.


first, terminology. just as when describing track or bus I/O configuration, 
"mono" and 'stereo" just doesn't really work very well. 

simpler to describe things in terms of number of inputs and number of outputs.

with 1 input to 1 output: no panning
1 input to 2 output: simple panning
2 inputs to 2 outputs:  

in this last case you have to consider the desired "width" of the signal, as 
well as possible phase relationships between the 2 inputs. in many scenarios 
it would be technically wrong to ever sent the "L" input to the "R" speaker 
and vice versa, but in others it may be ok. and the user might want it to be 
ok in every case.

etc.
 



Ah yes, I would lose separation 'width' when this 'stereo pan' would be 
 adjusted from center. Which may cause phasing problems. More to consider.
One option might be to give each channel its own pan and be done with it.

Cool that Ardour and NON have multi-channel strips and NON 'spatialization'. 
I painstakingly considered making all our strips multi-channel but decided
 against it due to complexity, so I only support multi-channel
 soft synthesizers, not the strips themselves which remain max 2 channels. 

Thanks.
Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixing audio: Implementing pan and balance

[Tim E. Real]

On March 12, 2013 03:08:18 PM Tim E. Real wrote:
> On March 12, 2013 08:41:01 PM you wrote:
> > On 03/12/2013 04:23 PM, Tim E. Real wrote:
> > > Hi, I need some advice, clear up some confusion:
> > > 
> > > I noticed our app uses this pan formula:
> > >   vol_L = volume * (1.0 - pan);
> > >   vol_R = volume * (1.0 + pan);
> > >   
> > >   where volume is the fader value, pan is the pan knob value
> > >   which ranges between -1.0 and 1.0, and vol_L and vol_R are the
> > >   factors to be applied to the data when sending a mono signal
> > >   to a stereo bus.
> > > 
> > > When pan is center, 100% of the signal is sent to L and R.
> > > At pan extremities, the signal is boosted by 3dB.
> > > 
> > > But according to [1], we should be using a Pan Law [2],
> > > 
> > >   where pan center is around 3dB to 6dB down and pan
> > >   extremities is full signal.
> > > 
> > > So I want to change how we mix mono -> stereo and use
> > > 
> > >   true Pan Law. I could add a Pan Law selector, seems like it
> > >   might be useful for various studio acoustics.
> > > 
> > > Then I noticed we use the same formula above to apply 'balance'
> > > 
> > >   (using the same pan knob) when sending a stereo signal to
> > >   a stereo bus.
> > > 
> > > But according to [3] we should be using a true balance control, not
> > > those
> > > 
> > >   same pan factors above. And according to [1]:
> > > "Note that mixers which have stereo input channels controlled by a
> > > single
> > > 
> > >   pan pot are in fact using the balance control architecture in those
> > >   channels, not pan control."
> > > 
> > > So I want to change how we mix stereo -> stereo and use true balance.
> > > 
> > > But then I checked some other apps to see what they do.
> > > In an unofficial test I noticed that QTractor seems to do the same
> > > thing,
> > > 
> > >   that is, when pan is adjusted on a stereo track, one meter goes up
> > >   while
> > >   the other goes down. RG seems not to have stereo meters and Ardour
> > >   I couldn't seem to make pan affect the meters, I will try some more.
> > > 
> > > My questions:
> > > 
> > > Is the pan formula above popular?
> > > 
> > > What is the consensus on stereo balance - use a Pan Law, being the
> > > 
> > >   formula above or otherwise, or use a true balance?
> > > 
> > > What should I do in the remaining case sending a stereo signal to a mono
> > > bus? If I am using a Pan Law as balance, the two signals will have
> > > already been>
> > > 
> > >   attenuated at pan center so I could simply sum the two channels
> > >   together.
> > > 
> > > But if instead I use true balance, at center the two signals are 100%.
> > > So should I attenuate the signals before summing them to a mono bus?
> > > Currently as our pan formula above shows, there would be no attenuation.
> > 
> > you are right - it should attenuate in the middle and gain increase as
> > you move. i hate balance controls because you can't move the image
> > around the panorama. if you have a stereo piano sample for example, you
> > need to move all the "sample data" around the sound stage - not hear an
> > amplified L channel and an attenuated R channel which is the balance
> > model. Balance is for home stereo's. Pan is for grown ups :)
> 
> OK just to be clear I was not implying that the given pan formula
>  would be used to do a true 'stereo pan', just that the formula would be
> used to adjust stereo 'balance' giving almost the same results as a true
> stereo balance, but slightly different levels, but not a true 'stereo pan'.
> 
> But having said that, yes I'm wondering about a true 'stereo pan' feature.
> How would such a feature work?
> I imagine that if for example if there is sound exclusively on the L
> channel, and 'stereo pan' is at center then moved all the way to the right,
> the sound that was exclusively on the L channel now moves to the exact
> center? That is, all the sound in the stereo field now moves 90 degrees to
> the right? It means you'd never be able to completely move an exclusive
> sound which was strictly on L, all the way to the right.

Ah, the answer might be an 'expanded' pan range of -180 to +180 degrees
 instead of the normal -90 to +90.
That way something all the way on L could be moved all the way to R.
Right?
Tim.

> 
> Does that sound correct Geoff?
> I can easily implement a true 'stereo pan', given some rules.
> Just, now I'd have to give the user the option of using either pan or
> balance, complicating things a wee bit more, but probably nothing an
> additional small pushbutton or two couldn't fix.
> 
> Thanks.
> Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mixing audio: Implementing pan and balance

[Tim E. Real]

On March 12, 2013 08:41:01 PM you wrote:
> On 03/12/2013 04:23 PM, Tim E. Real wrote:
> > Hi, I need some advice, clear up some confusion:
> > 
> > I noticed our app uses this pan formula:
> > vol_L = volume * (1.0 - pan);
> > vol_R = volume * (1.0 + pan);
> > 
> >   where volume is the fader value, pan is the pan knob value
> >   which ranges between -1.0 and 1.0, and vol_L and vol_R are the
> >   factors to be applied to the data when sending a mono signal
> >   to a stereo bus.
> > 
> > When pan is center, 100% of the signal is sent to L and R.
> > At pan extremities, the signal is boosted by 3dB.
> > 
> > But according to [1], we should be using a Pan Law [2],
> > 
> >   where pan center is around 3dB to 6dB down and pan
> >   extremities is full signal.
> > 
> > So I want to change how we mix mono -> stereo and use
> > 
> >   true Pan Law. I could add a Pan Law selector, seems like it
> >   might be useful for various studio acoustics.
> > 
> > Then I noticed we use the same formula above to apply 'balance'
> > 
> >   (using the same pan knob) when sending a stereo signal to
> >   a stereo bus.
> > 
> > But according to [3] we should be using a true balance control, not those
> > 
> >   same pan factors above. And according to [1]:
> > "Note that mixers which have stereo input channels controlled by a single
> > 
> >   pan pot are in fact using the balance control architecture in those
> >   channels, not pan control."
> > 
> > So I want to change how we mix stereo -> stereo and use true balance.
> > 
> > But then I checked some other apps to see what they do.
> > In an unofficial test I noticed that QTractor seems to do the same thing,
> > 
> >   that is, when pan is adjusted on a stereo track, one meter goes up while
> >   the other goes down. RG seems not to have stereo meters and Ardour
> >   I couldn't seem to make pan affect the meters, I will try some more.
> > 
> > My questions:
> > 
> > Is the pan formula above popular?
> > 
> > What is the consensus on stereo balance - use a Pan Law, being the
> > 
> >   formula above or otherwise, or use a true balance?
> > 
> > What should I do in the remaining case sending a stereo signal to a mono
> > bus? If I am using a Pan Law as balance, the two signals will have
> > already been> 
> >   attenuated at pan center so I could simply sum the two channels
> >   together.
> > 
> > But if instead I use true balance, at center the two signals are 100%.
> > So should I attenuate the signals before summing them to a mono bus?
> > Currently as our pan formula above shows, there would be no attenuation.
> 
> you are right - it should attenuate in the middle and gain increase as
> you move. i hate balance controls because you can't move the image
> around the panorama. if you have a stereo piano sample for example, you
> need to move all the "sample data" around the sound stage - not hear an
> amplified L channel and an attenuated R channel which is the balance
> model. Balance is for home stereo's. Pan is for grown ups :)

OK just to be clear I was not implying that the given pan formula
 would be used to do a true 'stereo pan', just that the formula would be used
 to adjust stereo 'balance' giving almost the same results as a true stereo
 balance, but slightly different levels, but not a true 'stereo pan'.

But having said that, yes I'm wondering about a true 'stereo pan' feature.
How would such a feature work?
I imagine that if for example if there is sound exclusively on the L channel, 
 and 'stereo pan' is at center then moved all the way to the right, the sound 
 that was exclusively on the L channel now moves to the exact center?
That is, all the sound in the stereo field now moves 90 degrees to the right?
It means you'd never be able to completely move an exclusive sound 
 which was strictly on L, all the way to the right.

Does that sound correct Geoff? 
I can easily implement a true 'stereo pan', given some rules.
Just, now I'd have to give the user the option of using either pan or balance,
 complicating things a wee bit more, but probably nothing an additional 
 small pushbutton or two couldn't fix.

Thanks.
Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Mixing audio: Implementing pan and balance

[Tim E. Real]

Hi, I need some advice, clear up some confusion:

I noticed our app uses this pan formula:

vol_L = volume * (1.0 - pan);
vol_R = volume * (1.0 + pan);

 where volume is the fader value, pan is the pan knob value
 which ranges between -1.0 and 1.0, and vol_L and vol_R are the 
 factors to be applied to the data when sending a mono signal 
 to a stereo bus.

When pan is center, 100% of the signal is sent to L and R.
At pan extremities, the signal is boosted by 3dB.

But according to [1], we should be using a Pan Law [2],
 where pan center is around 3dB to 6dB down and pan 
 extremities is full signal.

So I want to change how we mix mono -> stereo and use 
 true Pan Law. I could add a Pan Law selector, seems like it 
 might be useful for various studio acoustics.

Then I noticed we use the same formula above to apply 'balance'
 (using the same pan knob) when sending a stereo signal to
 a stereo bus.

But according to [3] we should be using a true balance control, not those 
 same pan factors above. And according to [1]:
"Note that mixers which have stereo input channels controlled by a single 
 pan pot are in fact using the balance control architecture in those channels, 
 not pan control."

So I want to change how we mix stereo -> stereo and use true balance.

But then I checked some other apps to see what they do.
In an unofficial test I noticed that QTractor seems to do the same thing,
 that is, when pan is adjusted on a stereo track, one meter goes up while 
 the other goes down. RG seems not to have stereo meters and Ardour
 I couldn't seem to make pan affect the meters, I will try some more.
 
My questions:

Is the pan formula above popular?

What is the consensus on stereo balance - use a Pan Law, being the 
 formula above or otherwise, or use a true balance?

What should I do in the remaining case sending a stereo signal to a mono bus?
If I am using a Pan Law as balance, the two signals will have already been 
 attenuated at pan center so I could simply sum the two channels together.
But if instead I use true balance, at center the two signals are 100%. 
So should I attenuate the signals before summing them to a mono bus?
Currently as our pan formula above shows, there would be no attenuation.

Thanks.
Tim.

[1]
http://en.wikipedia.org/wiki/Panning_%28audio%29
[2]
http://en.wikipedia.org/wiki/Pan_law
[3]
http://www.rane.com/par-b.html#balance

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Fwd: Re: Muse - Was: OT: Bitwig beta for Linux reviewed

[Tim E. Real]

On March 8, 2013 11:47:52 PM Ralf Mardorf wrote:
> On Fri, 2013-03-08 at 16:37 -0500, Tim E. Real wrote:
> > On March 8, 2013 09:31:50 PM Ralf Mardorf wrote:
> > > IIRC Muse can mute individual clips, but Muse never was
> > > able to run on my machine. I tested it for different distros, in
> > > different years.
> > 
> > Howdy, Ralf.
> > Can you give us an idea of why this might be?
> > Any clues at all, like choice of kernels, tweaks, RTIRQs etc.
> > Can you briefly describe the hardware involved?
> > I imagine you must run a pretty tight setup there.
> > 
> > Your experience with MusE is important to us.
> > We'd like to try to correct whatever the problem is, with your help.
> 
> I'm short in time this month, I can spend some time at the end of the
> month and install Muse again.
> 
> The PC is an ASUS M2A-VM HDMI with an on-board ATI Radeon X 1250-based
> graphics, in the past I sometimes replaced it by a PCIe NVIDIA GeForce
> 7200 GS.
> 
> In the past the PC first had one, later two TerraTec EWX 24/96 ICE1712
> PCI cards, for more then a year I'm using it with those two cards for
> MIDI and a RME HDSPe AIO for MIDI and audio.
> 
> The CPU always was and still is an AMD Athlon 64-bit dual-core BE-2350
> 2.1 GHz. I started with 2 GiB RAM, but early extended to 4 GiB.
> 
> FWIW the PCIe RME card not only is bad supported, on my machine I still
> get xruns with very high latency, when using the RME card, but Muse
> already had issues on my machine, when I used the TerraTec cards only,
> that can be used without xruns at a passable latency.
> 
> I'm usually using self-build kernel-rt in the past 2.6.x and today 3.x.
> 
> Nothing does share the IRQ with a sound card.
> 
> I also tried to tune the machine by:
> 
> ### Bluetooth
> service bluetooth stop
> 
> ### TerraTec EWX 24/96
> modprobe -r snd_ice1712
> 
> ### Others
> modprobe -r firewire-ohci
> modprobe -r firewire_core
> service cups stop
> modprobe -r ppdev # parallel port
> modprobe -r lp# printer
> 
> ### Unbinding devices
> echo -n ":00:13.2" > /sys/bus/pci/drivers/ohci_hcd/unbind
> echo -n ":00:13.4" > /sys/bus/pci/drivers/ohci_hcd/unbind
> 
> This doesn't improve the situation. However, xruns were not the issues,
> IIRC Muse usually freeze and is completely unusable here. Architecture
> of the Linux usually is 64-bit, I don't know if I ever tried Muse on a
> 32-bit install. I'm using Jack2 only, first regarding to the alsarawmidi
> switch, to get rid of MIDI hardware jitter and because Jack1 never
> worked on this Computer and also not on my first PC, an ASRock K7VT2
> with an 800 MHz single core, 32-bit Athlon. All versions of Jack1 I
> tested, not only the version that was known to do this, disconnected
> clients.
> 
> Onboard audio always is disabled, Northbridge AMD 690G, Southbridge ATI
> SB600, 1 * PCI Express x16, 1 * PCI Express x1, 2 * PCI.
> 
> At the moment I'm booted to Arch Linux, the only installed audio
> software at the moment are Jack2 and Simple Sysexxer and I've got no
> time to test Muse right now. >= 22. March I might have some time to test
> Muse. If I should forget to test Muse, at the end of this month or
> during next month please ask me again.
> 
> Regards,
> Ralf
> 

OK. Great! Thanks for the info. I'll wait a while.

I also run MusE on an AMD 64, an Athlon. It is single-core, a bit old now.
With a Delta1010 ice1712 card.
I blacklisted my on-board audio because even when I disable it in BIOS, the 
 OS still somehow finds it and pollutes the daily ordering of device listings.

There is a MusE command-line debug switch -D which gives us information. 
Sometimes it can be a plugin or soft synth misbehaving with us. 
There are switches to turn off loading of the plugins and soft synths.
Hopefully these will help narrow it down.
I fixed a freeze or two recently, kind of obscure though.

Current release is 2.1.1, next is due out soon, plenty of great new fixes
 and features, and new online docs. Would be cool if you could run a 
 recent version but it might require building source but it's not too hard. 
We have removed the Doxygen requirement for example :)

As a midi editor she's fairly advanced, per-drum or note midi controllers 
 like poly-aftertouch for example.

But, gulp, we're about to face some seeerious competition on two fronts.
Oh, apologies for breaking in on this Bitwig thread, carry on.
And congratulations to the Ardour team expecting the new baby! 
'Gonna hand out some cigars?

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] OT: Bitwig beta for Linux reviewed

[Tim E. Real]

On March 8, 2013 09:31:50 PM Ralf Mardorf wrote:
> IIRC Muse can mute individual clips, but Muse never was
> able to run on my machine. I tested it for different distros, in
> different years.

Howdy, Ralf.
Can you give us an idea of why this might be?
Any clues at all, like choice of kernels, tweaks, RTIRQs etc.
Can you briefly describe the hardware involved?
I imagine you must run a pretty tight setup there.

Your experience with MusE is important to us.
We'd like to try to correct whatever the problem is, with your help.

Thanks.
Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] So what do you think sucks about Linux audio ?

[Tim E. Real]

On February 5, 2013 08:18:03 PM Pedro Lopez-Cabanillas wrote:
> On Tuesday 05 February 2013 18:26:24 David Baron wrote:
> > My main complaint is not really about Linux, per se, but the whole DAW,
> > etc., scene: Lack of interoperability!
> > 
> > I have a lot of Cakewalk files from the Windows days. 

Me too.

> > Cannot do anything
> > with them besides play two tracks in Cakewalk-Express using WINE.

I'm currently running CW in Wine and exporting the audio tracks
 one-by-one, and then save the file as midi.

This gives me the midi and audio files which I then import into MusE.
But it's tedious of course. I'm writing support for making it easier
 since I discovered I need to link imported midi controllers to the 
 audio tracks, which MusE currently can't do...

> 
> That is because you have been ignoring that KMidimon reads and plays
> Cakewalk WRK files. And my library drumstick-file is available under a free
> license, offering this functionality to any interested developer.

Wow. The drumstick lib reads wrk files?

Awesome. I had no idea, was looking for something. 
Having a look at the source now...

Can you tell me if it might be able to handle the audio tracks as well?

And (just a wish) is it possible to make a .bun bundle file parser?

Thanks very much Pedro!

Tim.

> 
> For me, this says everything about the worse problem in the Linux audio
> development community.
> 
> Regards
> 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Mudita24 release 1.1.0

[Tim E. Real]

Hello.
I finally rolled an archive.

This is for the benefit of ye kind packagers out there, and everyone, 
 as I notice the version in Ubuntu for example is still the old version 
 which has broken alsactrl profile support - can't save/load profiles.

There has been no changes to code for a while, except that
 I just now removed the SVN version from the About page.

However, the most recent major changes from a while ago are 
 important, such as profile fixes, and are not in the last release, 
 so it is important to get this release out there.

Mudita24 is a modification of the Linux alsa-tools' envy24control(1): 
 an application controlling the digital mixer, channel gains and other 
 hardware settings for sound cards based on the VIA Ice1712 chipset 
 aka Envy24.

Project home page:
http://code.google.com/p/mudita24/

Download source code:
http://mudita24.googlecode.com/files/mudita24-1.1.0.tar.gz

Let us know if any problems. 

Thanks. Tim.
The Mudita24 project.
The MusE project.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ann] CAPS 0.9.4

[Tim E. Real]

On January 13, 2013 09:45:58 PM Tim Goetze wrote:
> [Tim E. Real]
> 
> >Applied patch. The model seems to still make very little difference.
> >Hard to tell, but it seems like only model 7 sounds different than the
> >rest. Also hard to tell but the brightness seems to make no difference.
> >Should there be so little difference in these settings?
> 
> Situated rather early in the signal path, the tonestack's influence on
> the sound will lessen as more gain is applied.  (The model switches
> found on commercial amp emulators will very likely also change a host
> of other circuit characteristics in addition to the tonestack, so the
> sound change will be much more pronounced.  I prefer to expose those
> characteristics with fully independent controls.)
> 
> The current tonestack model 7 is from a very small amp and it comes
> with an unusually great amount of treble cut and bass boost designed
> into it, probably intended to compensate for the poor bass response of
> the small loudspeaker and casing.
> 
> The 'bright' filter is located between the two saturating stages so,
> like the tonestack's, its effects are less pronounced when high gain
> drives the poweramp stage into heavy saturation.  Also, when you turn
> up 'gain' and/or 'power', the range of the 'bright' control is reduced
> in order to unmap unusable regions of the parameter space.  Anyway,
> you may still notice that lower 'bright' settings can help to clean up
> hi-gain noise, especially in notes higher up the neck.
> 
> You could replace the 'bright' filter with a more intricate
> arrangement (I've been thinking about an experiment with a 4-way eq)
> to get further sound shaping options, but I think that more meaningful
> control over the hi-gain tone can be had by routing the amp's output
> through an additional equaliser.  Given the abundance of good eq
> plugins, there seemed to be no good reason to put one into the amp
> itself (though that may change too).

OK makes sense to me. Thanks.
My mistake, I "turned it down, man" and can now hear the differences
 with all controls.
After that, even with gain at full I can now recognize the differences.

Tim.

> 
> >Anyway, so far it sounds really good.
> >It seems a /lot/ more beefier than the old amp VTS.
> >I recall having to run a separate distortion plugin into the old VTS. No
> >more.
> Very glad to hear you like it.  I mostly play a cleanish sound
> (everything at default settings) but at some point it became apparent
> that even the clean tone will only work well if the amp can produce a
> great hi-gain sound.
> 
> Thanks,
> Tim

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ann] CAPS 0.9.4

[Tim E. Real]

On January 10, 2013 08:15:11 PM Tim Goetze wrote:
> [Gianfranco Ceccolini]
> 
> >when running AmpVTS in JackRack I hear no difference when changing the amp
> >models. when plugging the Tonestack plugin the difference is perfectly
> >audible.
> >
> >Something worng with AmpVTS?
> 
> Yes, it's a bug, thanks for pointing it out.  The attached patch fixes
> the problem.
> 
> Thanks for the feedback and the kind words!
> Tim

Applied patch. The model seems to still make very little difference.
Hard to tell, but it seems like only model 7 sounds different than the rest.
Also hard to tell but the brightness seems to make no difference.
Should there be so little difference in these settings?
I seem to remember the old VTS model setting changed the sound more.

Anyway, so far it sounds really good. 
It seems a /lot/ more beefier than the old amp VTS.
I recall having to run a separate distortion plugin into the old VTS. No more.

Thanks.
(Another) Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Plugin buffer size restrictions

[Tim E. Real]

On May 26, 2012 10:02:32 AM Fons Adriaensen wrote:
> On Fri, May 25, 2012 at 10:43:36PM -0400, David Robillard wrote:
> > I am making an LV2 extension for accessing and/or restricting the buffer
> > size.  This is straightforward, but I need to know just what
> > restrictions are actually needed by various sorts of DSP.
> > 
> > The sort of thing we're looking for here is "buffer size is always at
> > least 123 frames" or "buffer size is always a power of 2" or "buffer
> > size is always a multiple of 123".
> > 
> > I know "multiple of a power of two" is needed for convolution.  Not sure
> > what else...
> 
> It's not really *needed*, an FFT-based process can be designed to
> work with arbitrary and variable buffer sizes provided
> 
> * this is known at init time,
> * and the user accepts the additional latency.
> 
> 'Power of 2' in practice means 'a power of two that is not
> too small to make things inefficient'. So the plugin should
> have the option to require a minimum size as well, e.g. 64.
> 
> But I doubt very much if your extension is going to have much
> impact. I expect most hosts to simply ignore it, as implementing
> it could be quite invasive. Imagine a host having a chain a plugins
> in e.g. a channel strip. If one of them requires this extension
> and the host relies on variable buffer size to provide 'sample
> accurate' control of the others, then the host is required to
> implement extra buffering for that plugin. Probably no-go, some
> hosts even refuse plugins that don't work 'in place', even if
> the solution in that case is much simpler.
> 
> The following is part of a report on LV2 I was asked to
> write some months ago:
> 
> ==
> 
> Audio processing (on PCs) is usually done in blocks of frames,
> so all components are designed to work that way, There are at
> least 4 possible ways the block size of a module or plugin
> could be defined:
> 
>   1. Fixed at compile time.
>   2. Fixed at instantiation, power of 2 [*]
>   3. Fixed at instantiation, any (reasonable) value.
>   4. Variable - can be different in each process() call.
> 
> [*]  Or a similar restriction, e.g. either 2^N or 3*2^N.
> For example some FFT based processes could be designed to
> allow a block size of 3*2^N, or even 5*2^N, while making
> it accept any size would be out of the question in many
> cases.
> 
> Clearly (1) is undesirable, and it will not be considered
> further. Some algorithms require (2) in order to meet their
> specs. They could be made to work with any block size, but
> this usually means extra latency, or some other form of loss
> of performance.
> 
> Almost all more sophisticated audio processing algorithms can
> be implemented more easily and usually more efficiently if (3)
> is guaranteed, even if the block size itself plays no role in
> their definition and does not affect their output in any way.
> This is in particular true for algorithms that partially run
> using some internal block size (determined by e.g. the sample
> rate and some combination of parameters), or those that have
> to manage a long history or complex state as part of their
> operation.
> 
> It is almost always possible to allow (4), the exceptions are
> the cases mentioned above that require (2). But an algorithm
> that should perform well will have to be designed so that the
> output it produces does not in any way depend on the actual
> block sizes used at run time.
> 
> This includes ignoring any attempt to e.g. control the rate of
> change of its internal parameters by a caller playing with the
> block size for each process() call. The idea that one could
> achieve 'sample accurate' control of an audio process in this
> way is a either a fallacy or irrelevant, depending on the case
> and how you look at it.
> 
> All this means that there is *no reason* to ever require (4),
> of a plugin or module, and no serious plugin standard or
> modular audio application should ever do this.
> 
> Yet that is precisely what LV2 does. While it is designed
> to be flexible and extensible, the one and only part of its
> specs that is fixed but shouldn't have been gets it wrong.
> 
> And allowing an extension to override this is not going to
> work, because such an extension can be very invasive to a
> host. If a host, e.g. Ardour, is from the start designed to
> exploit the freedom of (4), be it for the wrong reasons, it
> is never going to adopt an extension that would cripple major
> parts of its functionality, e.g. automation, or force them
> to be redesigned. Even less so if the plugin system does not
> provide an alternative way, guaranteed to work with any plugin,
> to obtain the same result.
> 
> This is the really sad aspect of the situation: LV2 requires
> so little of a plugin that in order to make things like e.g.
> automation possible it must allow hacks such as playing with
> the block size of each call. So hosts will do this, and that
> wart will never go away.
> 
> Things should have been the other way round: allowing

Re: [LAD] Non Session Management

[Tim E. Real]

On March 22, 2012 4:42:55 PM rosea.grammostola wrote:
> On 03/22/2012 02:52 PM, Harry van Haaren wrote:
> > On Thu, Mar 22, 2012 at 12:33 PM, rosea.grammostola
> > 
> > mailto:rosea.grammost...@gmail.com>> wrote:
> > JackSession seems to be an option
> > 
> > JackSession is merged in JACK. No external dependencies, if all other
> > session management systems would integrate with it, then the problem
> > would be solved. I appreciate that there are things that JackSession
> > cannot currently do, but IMO there's a lot to be gained from widespread
> > adopting of JackSession.
> > 
> > When I find time to implement restoring sessions in Luppp, the
> > functionality will be available trough JackSession.
> 
> And what if there is no real objection towards NSM from within the
> community and what if the JS devs tell you that they have no time or
> motivation to really develop or stimulate development of JackSession?
> Isn't is possible then that the community more or less decides that one
> option is better then the other?
> Or is someone else willing to maintain JackSession from now on?
> 
> NSM doesn't depend on JACK, how bad is that really? At least one benefit
> seems to be that apps like non-mixer are also supported now. And even
> apps without JACK support, (all though I can't find a situation at this
> moment in time where this can be useful).

Our MusE allows running without Jack, using a dummy audio driver and
 ALSA for midi. Some folks run it that way.

(I was told MusE had an ALSA audio driver long ago, I was thinking 
 of toying with that again to help get users running. A recent post on 
 jack-dev lamented the lack of ALSA audio support in several apps, 
 including ours.)

So I've often wondered whether we should try to add JS support.
I think for us, we still need a SM that works with and without Jack.
We've always had LASH support. With LADISH LASH emulation, 
 maybe we won't have to do anything... for now.

I remember early threads about NON internals, it seemed to have smart design.

Cheers. Tim.

> 
> In my view all depends on the vision of the LAD community. I just tried
> NSM yesterday, but what if it's the best solution overall? That's
> possible right, that someone suddenly comes up with the best solution so
> far. If NSM is that best solution, we might go for it. Otherwise we have
> to think about keeping JackSession alive.
> 
> Harry, maybe it's good to give NSM a shot and/ or to comment on the API.
> 

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] send midi message

[Tim E. Real]

On January 6, 2012 1:32:36 PM Dave Stikkolorum wrote:
> On 06-01-12 13:22, Paul Davis wrote:
> > On Fri, Jan 6, 2012 at 7:13 AM, Dave Stikkolorum  wrote:
> >> Not the communication, but I think Hydrogen over jack has more delay
> >> then directly,
> >> but I don't know this for sure.
> > 
> > the use of JACK adds no delay.
> > 
> >> Also jack causes other , not jack programs like audio plugins for
> >> browser, to hang/stop.
> > 
> > http://jackaudio.org/faq
> > 
> >> Why is jack / or an other audio layer not completely integrated like
> >> in
> >> windows and mac os,
> > 
> > its not completely integrated on either of those platform. if you want
> > to route audio between applications on windows or OS X, guess what
> > your likely first choice technology is going to be?
> 
> Ok, maybe that's true. But the use is in the basic situations more
> simple I think.
> don't get me wrong. I am a linux fan anyway ;)
> 
> > also, because this is linux. there is nobody around to force such
> > things.
> 
> Ok, that's true.
> Sometimes I get very frustrated to start all these applications seperatly.
> Also lash seems to be dead(according to it's creator).

LADISH has stepped in as a emulating replacement for LASH.
By now it may be fully functional. 
Nedko, is it working yet?

Tim.

> And I don't think Jack sessions is going to be adopted by al these programs.
> 
> 

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Question re midi

[Tim E. Real]

On December 12, 2011 11:53:35 PM gene heskett wrote:
> Does anyone have, in their old yellowed dead tree archives, a list of
> instrument numbers vs instrument that would allow one to setup a
> translation table to massage some very old midi files into General Midi
> instrument numbers?  I need a list of number vs instrument for the truly
> elderly Casio CZ-101 and for the Casio MT-240.
> 
> Google doesn't seem to be a lot of help and the original users manual for
> the MT-240 very carefully skips that.
> 
> Some music I moused in 20 years ago sounds terrible when played through a
> modern GM player.  Something has turned into a screaming Picolo and is
> threatening to burn out my tweeters.
> 
> Any help will be very muchly appreciated.
> 
> Thanks.
> 
> Cheers, Gene

I downloaded the MT-240 manual.
What about information on page 18 - any use?

It says midi program 20 thru 29 produce the preset tones and lists them.
The manual says it produces the 210 tone bank sounds by layering these 
 presets together.

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Another call for brave testers: new Guitarix LADSPA plugins

[Tim E. Real]

On November 26, 2011 12:40:01 AM Andreas Degert wrote:
> Hi,
> 
> we'd like to ask those who are interested in the new Guitarix LADSPA
> plugins to run them on their systems and give us some feedback. They
> do fine on our own machines and seem to be fit for wider testing.
> 
> The plugins "Guitarix Amp" and "Guitarix Stereo Fx" wrap all of the
> entire sound engine of Guitarix. You can load a preset that you defined
> with the Guitarix program, and even define some parameters for DAW
> automation.
> 
> It's explained in our wiki:
> 
> https://sourceforge.net/apps/mediawiki/guitarix/index.php?title=How_to_use_t
> he_new_ladspa_plugins
> 
> Our SVN:
> 
> svn co http://guitarix.svn.sourceforge.net/svnroot/guitarix/trunk guitarix
> 
> After checkout, build with
> 
> ./waf configure && ./waf && sudo ./waf install
> 
> for an installation to /usr/local.
> 
> Our tracker:
> http://sourceforge.net/tracker/?group_id=236234
> 
> Your feedback will be welcome here or there or anywhere..
> 
> Or in our forum:
> http://sourceforge.net/apps/phpbb/guitarix/
> 
> so please, don't be shy and tell us your test results or
> if you think the concept is usable / unusable :-)
> 
> ciao
> Andreas


Thanks. This is awesome news! Will test.

I was actually trying to do the very same thing here!

Creating individual GX Head Amp LADSPA plugins is super easy, 
 like '12AX7' for example. Faust makes it easy.

But combining them all in one plugin, or even just combining
 them all in one .so file was very difficult.
I had some success, but some serious drawbacks.

And then there's the GX cabinets, which I would have needed
 to extract from GX and make plugins from.

Faust is nice, very powerful, makes it easy, but does make some 'automated' 
 aspects hard. 

This is great news because having the GX Head sound in LADSPA form 
 means having no round-trip latency from using GX externally.

PS. I actually fixed the existing Guitarix Distortion plugin by 
 composing my own .dsp file (the original has long since been missing) 
 and compiling.
It proved that the 'Drive Level' control was indeed broken in the existing
 .cc file. Yet, it was still disappointing after all that work, it doesn't 
 really help the sound much.

Cheers. Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Some mudita24 fixes in SVN now.

[Tim E. Real]

Hi list, Niels, James. (Sorry for the repost.)

I have moved the existing code into an attic branch.
This code contains support for very old GTK+ versions, even pre-2.4. 
Most users should not use it, but it's there if you need it.
I'll try to put out a legacy release on the project page.

James' supplied patch has been applied to trunk.
The patch fixes some deprecated code and modernizes.
I tried his suggested deprecated GTK+ code removal compiler flags,
 but I gather there is more work to be done modernizing the
 code, as it will not compile yet with the flags. 

I removed all support for very old GTK+ versions in trunk, and have 
 set the minimum required GTK+ version at 2.20 for now.
 
READMEs, and some name strings, have been updated for mudita24.

So, if James or anyone else would like to help with mudita24,
 you are no longer encumbered by the legacy code and are free to do 
 what you need to move the program forward, for now and the future.

Thanks. Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Ignore. Testing mail...

[Tim E. Real]

Just testing
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Some mudita24 fixes in SVN now.

[Tim E. Real]

Hello.
I noticed mudita24 SVN was in a sad state, crashing the whole system.

There were already significant changes and improvements since release 1.0.3
So I fixed 'er up. Please give it a spin so we can put out a release sometime.

mudita24 is the updated replacement of envy24control, the gui for 
 ice1712-based audio hardware.
 
http://code.google.com/p/mudita24/

subversion: svn checkout http://mudita24.googlecode.com/svn/trunk/mudita24
 mudita24-svn 

1) Moved to cmake build system. No more autotools   :)
(The default install location is /usr/local. It can be changed -
  try the handy 'ccmake' gui).
2) Fixed wrong alsactl location. Now cmake looks for alsactl. 
   Override with environment variable ALSACTL_PROG. 
3) Added usage info. 
4) Fixed serious fatal X error: height too big. Was far too many markings, 
 brought down the system, due to lowest alsa db value now returning 
-999. Installed some limits.   
5) Executable is now called mudita24 instead of envy24control.
This should help kind packagers out there finally get this into the repos.

Cheers.   Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] a *simple* ring buffer, comments pls?

[Tim E. Real]

On July 11, 2011 04:50:06 pm Chris Cannam wrote:
> I know taking locks in a RT process is deeply frowned upon

Likely been answered before, but good time for me to ask:
What is the reason it is not recommended?
Is it simply because of a long time involved in acquiring the lock, or is it 
 because the lock might block some other Jack thread from running?

The same reason why other things like 'malloc' or 'new' are not 
 recommended either?

Thanks. Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio format abadie.jo

[Tim E. Real]

On July 6, 2011 07:11:49 pm Tim E. Real wrote:
> Hi Florian. We meet again, on LAD!

Oops, you are not Florian the MusE devel?
Greetings anyway.
Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] audio format abadie.jo

[Tim E. Real]

On July 6, 2011 05:33:44 am Florian Paul Schmidt wrote:
> On 06/29/2011 04:06 AM, pierre jocelyn andre wrote:
> > Bonjour,
> > j'ai créé un nouveau format audio destiné à linux. Je suis à la recherche
> > d'aide pour finir le langage C, pour tester, et pour créer une nouvelle
> > générationde carte audio. J'arrive à créer des fichier audio avec des
> > voix humaines de plusieurs Ko avec seulement 10 octets.
> > La page d'avancement de mon projet audio se trouve ici :
> > Http://www.letime.net/legere/index.html
>
> Hi,
>
> I think you'll get more responses if you state your text in english.
> Good luck,
> Flo

Hi Florian. We meet again, on LAD!

I think he says he has created a new audio format for Linux.
He's looking for help with the C language, testing, and creating a new
 generation of audio card.
The next part I'm not sure. I think it says he has created an audio file
 with human voices using only ten octaves? Don't know what 'Ko' is.

I'm English Canadian with some French knowledge.
We were all taught French in school, long ago.
Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Strange gettimeofday behaviour - out of order times.

[Tim E. Real]

On May 4, 2011 08:20:51 pm you wrote:
> On Wed, May 4, 2011 at 7:11 PM, Tim E. Real  wrote:
> > I discovered gettimeofday occasionally gives me a time value
> >  which is less than a previous time value. The value is actually
> >  'out of order' and really belongs ahead of a few others,
> >  according to examined printouts.
> >
> > So I tried  clock_gettime(CLOCK_MONOTONIC, ..), same result.
>
> i believe you want CLOCK_REALTIME. however, if CLOCK_MONOTONIC is
> malfunctioning and you can prove it with a very small piece of code,
> the kernel guys will want to know.
>
> > Still checking some things, maybe there's a reason, the app's fault.
> > From what I've read gettimeofday is thread safe, but the incorrect
> >  time values are being read by the same thread always.
>
> gettimeofday() is subject to system time corrections (e.g. via NTP).
> it is never ever guaranteed to be monotonic.

Weird, CLOCK_REALTIME does it too. 
Only CLOCK_PROCESS_CPUTIME_ID does not.

Been reading, according to places like this:

http://stackoverflow.com/questions/3523442/difference-between-clock-realtime-
and-clock-monotonic

http://stackoverflow.com/questions/3657289/linux-clock-gettimeclock-monotonic-
strange-non-monotonic-behavior

CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW are not supposed to go backwards 
 but apparently CLOCK_MONOTONIC just might and CLOCK_MONOTONIC_RAW is better, 
 and CLOCK_REALTIME is less reliable than that.

However on that second page it mentions a kernel fix, more recent than mine.
Mine also doesn't seem to have CLOCK_MONOTONIC_RAW.

I am going to chalk it up to this older kernel, and test on my newer machine 
 and hope it vanishes...

In the meantime, I can make the code I'm working on tolerant. 
I'm just not sure how this affects the rest of the existing app code - 
 could this be the source of occasional bugs or have we just been lucky or
 is it already tolerant...

Thanks!


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Strange gettimeofday behaviour - out of order times.

[Tim E. Real]

I discovered gettimeofday occasionally gives me a time value
 which is less than a previous time value. The value is actually
 'out of order' and really belongs ahead of a few others,
 according to examined printouts.

So I tried  clock_gettime(CLOCK_MONOTONIC, ..), same result.

Then I tried  clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ..)
 and it appears to be OK so far, giving me what I want - truly linear time.

Still checking some things, maybe there's a reason, the app's fault.
>From what I've read gettimeofday is thread safe, but the incorrect
 time values are being read by the same thread always.

Any advice here, anyone seen this?

Also, when using Jack, is it advisable to choose the same
 clock method as Jack is using (cycle, hpet, system)?

Thanks. Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ann] CAPS 0.4.5

[Tim E. Real]

On April 14, 2011 06:59:34 am you wrote:
> On 13 April 2011 22:03, Tim E. Real  wrote:
> > I agree that if this new port were to be sandwiched among the others
> >  or if he were removing ports, that's breakage.
>
> I think that was the plan, though -- to put the new port after the
> other control ports and before any of the existing audio ones.  And
> that's the problem.
Oh I see. Not good. But doesn't audio come before controls?
I was in our code the other day and IIRC noticed audio came before controls.
(That's why I posted.) 
Or is that simply how port ordering is /presented/ to me from LADSPA?

Hypothetically, if the new port really did come after ALL others, would 
 that still break anything, including that LV2 bridge?
If MusE found some control ports followed by audio ports followed 
 by more control ports, it would still cope fine.

Thanks for the enlightenment.
I'm learning (l)rdf and LV2 stuff now, with an eye towards LV2 support. 
(I only recently learned what the 'L' stands for. Now it all makes sense - 
 it's LADSPA all grown up.)

Tim E.

>
> I like to disagree with David on most things LADSPA -- for example I
> think a host that uses the "unique" ID at all is broken from the
> outset, because there's no way to ensure that ID is actually unique,
> e.g. for plugin wrappers.  But in this case, and even though my own
> hosts should cope with Tim's change without problems, I have to agree
> that the change is not a good idea.
>
>
> Chris

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ann] CAPS 0.4.5

[Tim E. Real]

On April 13, 2011 05:03:45 pm you wrote:
> On April 13, 2011 02:11:02 pm David Robillard wrote:
> > On 12/04/11 06:00 AM, Tim Goetze wrote:
> > > [David Robillard]
> > >
> > >> No, the pragmatic thing to do is not deliberately break your plugin
> > >> when several knowledgeable people have pointed out that doing so can
> > >> cause countless problems.
> > >
> > > Again: not the plugin is broken, but the host that assumes the port
> > > signature not to change over different plugin versions.
> >
> > No, a given index on your plugin no longer refers to the same port,
> > therefore the interface to the plugin has been broken, period.
>
> But he only wants to add a new port, not change them around or
>  remove them, doesn't he? So the indexes are not changing.
> So long as this new port comes after all the others, including audio,
>  what's the problem? Our MusE can cope, can the others?
> I agree that if this new port were to be sandwiched among the others
>  or if he were removing ports, that's breakage.
> How is a plugin supposed to grow and mature?
> I mean the Caps ToneStack gained a few 'model' values over the years.
> Did it change unique ID?
> Every time he wants to add a new port he's got to change the ID?
> So we end up with ten different versions with ten different IDs?
> Maybe the others are referring to breaking lrdf (I'm just learning lrdf
> now). Or if someone tries to load a song referring to the new plugin
> version, on an older system having the old plugin version.
> But I know MusE can still handle that, when loading a song it just ignores
>  any port ID out of range of the number of ports.
> It's a tough decision I know, I empathize, and if the consensus is that
>  the ID should be changed, I guess you gotta do it.
> But surely we could accept this small change, can't we?
> I mean what, really, would break?
>
> Thanks.
> Tim E.
Ah, just read up the thread terribly sorry. LV2 issues and such plus
 that bridge. 

A new plugin would be best. 

It's OK, we see it in some other plugins, incremental upgrades.
I never seemed to notice or mind much, guess I've always assumed
 that maybe other versions were made by someone else. 

Tim E.

>
> > > There is no mention of such a requirement in the interface
> > > specification, therefore the assumption is invalid and the
> > > responsibility for potential breakage lies with the host.
> >
> > This "assumption" is obvious, since indices are the ID for a port. To
> > argue that this is not true is literally equivalent to arguing that
> > LADSPA does not support saving session/patch/etc files in any way, at
> > all, whatsoever, since indices are meaningless and can not be relied
> > upon to refer to the same port when the plugin is reloaded later.
> > Obviously this is absurd.
> >
> > Your assumption, that hosts must refer to ports by an index within a
> > special separate index namespace for control and audio ports, is a much
> > greater one: it is not obvious, and the alternative is not absurd. It
> > is, in other words, clearly not in the language or spirit of LADSPA.
> > There is no reason someone reading ladspa.h and writing an
> > implementation would reasonably come to the conclusion that this is the
> > required correct behavior.
> >
> > > It has been shown that properly designed hosts handle the port
> > > addition just fine.
> >
> > This is just conveniently, but erroneously, redefining "properly
> > designed hosts" to mean "hosts that won't break when I break my plugin
> > in this particular way".
> >
> > > You may of course argue - not entirely unreasonably - that it is more
> > > pragmatic for the plugin author to cater for broken hosts than to
> > > expect them to be fixed.  Do you?
> >
> > No, because the host is not broken, as myself and others (including one
> > of the main authors of LADSPA itself, and the main author of the host in
> > question) have explained several times over.
> >
> > You are trying to argue that LADSPA does not present this "assumption"
> > that indices refer to a constant port, but as mentioned above, this is
> > an obvious conclusion, since the alternative is absurd (ports clearly
> > must have /some/ ID). LADSPA certainly does not specify the more complex
> > definition of "correct" use of port indices that you are trying to
> > justify (nor should it, for several reasons, but that is beside the
> > point).
> >
> > The simplest, most obvious, and intended rule is: If a given port index
> > does not refer to the same port on a new version of a plugin, then the
> > plugin interface has broken and the plugin ID MUST be changed. As Fons
> > mentioned, this is effectively a different plugin.
> >
> > Your definition, which splits the port index namespace into two separate
> > namespaces, one for control and one for audio, is not obviously intended
> > and is not mentioned or alluded to anywhere in LADSPA whatsoever. Hosts
> > that do not do this are not broken. That every single host author who
> > has participated in t

Re: [LAD] [ann] CAPS 0.4.5

[Tim E. Real]

On April 13, 2011 02:11:02 pm David Robillard wrote:
> On 12/04/11 06:00 AM, Tim Goetze wrote:
> > [David Robillard]
> >
> >> No, the pragmatic thing to do is not deliberately break your plugin when
> >> several knowledgeable people have pointed out that doing so can cause
> >> countless problems.
> >
> > Again: not the plugin is broken, but the host that assumes the port
> > signature not to change over different plugin versions.
>
> No, a given index on your plugin no longer refers to the same port,
> therefore the interface to the plugin has been broken, period.
But he only wants to add a new port, not change them around or 
 remove them, doesn't he? So the indexes are not changing.
So long as this new port comes after all the others, including audio,
 what's the problem? Our MusE can cope, can the others?
I agree that if this new port were to be sandwiched among the others
 or if he were removing ports, that's breakage.
How is a plugin supposed to grow and mature?
I mean the Caps ToneStack gained a few 'model' values over the years.
Did it change unique ID?
Every time he wants to add a new port he's got to change the ID?
So we end up with ten different versions with ten different IDs?
Maybe the others are referring to breaking lrdf (I'm just learning lrdf now).
Or if someone tries to load a song referring to the new plugin version, 
 on an older system having the old plugin version.
But I know MusE can still handle that, when loading a song it just ignores 
 any port ID out of range of the number of ports.
It's a tough decision I know, I empathize, and if the consensus is that 
 the ID should be changed, I guess you gotta do it.
But surely we could accept this small change, can't we?
I mean what, really, would break?

Thanks.
Tim E.

>
> > There is no mention of such a requirement in the interface
> > specification, therefore the assumption is invalid and the
> > responsibility for potential breakage lies with the host.
>
> This "assumption" is obvious, since indices are the ID for a port. To
> argue that this is not true is literally equivalent to arguing that
> LADSPA does not support saving session/patch/etc files in any way, at
> all, whatsoever, since indices are meaningless and can not be relied
> upon to refer to the same port when the plugin is reloaded later.
> Obviously this is absurd.
>
> Your assumption, that hosts must refer to ports by an index within a
> special separate index namespace for control and audio ports, is a much
> greater one: it is not obvious, and the alternative is not absurd. It
> is, in other words, clearly not in the language or spirit of LADSPA.
> There is no reason someone reading ladspa.h and writing an
> implementation would reasonably come to the conclusion that this is the
> required correct behavior.
>
> > It has been shown that properly designed hosts handle the port
> > addition just fine.
>
> This is just conveniently, but erroneously, redefining "properly
> designed hosts" to mean "hosts that won't break when I break my plugin
> in this particular way".
>
> > You may of course argue - not entirely unreasonably - that it is more
> > pragmatic for the plugin author to cater for broken hosts than to
> > expect them to be fixed.  Do you?
>
> No, because the host is not broken, as myself and others (including one
> of the main authors of LADSPA itself, and the main author of the host in
> question) have explained several times over.
>
> You are trying to argue that LADSPA does not present this "assumption"
> that indices refer to a constant port, but as mentioned above, this is
> an obvious conclusion, since the alternative is absurd (ports clearly
> must have /some/ ID). LADSPA certainly does not specify the more complex
> definition of "correct" use of port indices that you are trying to
> justify (nor should it, for several reasons, but that is beside the point).
>
> The simplest, most obvious, and intended rule is: If a given port index
> does not refer to the same port on a new version of a plugin, then the
> plugin interface has broken and the plugin ID MUST be changed. As Fons
> mentioned, this is effectively a different plugin.
>
> Your definition, which splits the port index namespace into two separate
> namespaces, one for control and one for audio, is not obviously intended
> and is not mentioned or alluded to anywhere in LADSPA whatsoever. Hosts
> that do not do this are not broken. That every single host author who
> has participated in this thread agrees, and the fact that you need to
> add a version number so one can kludge around the broken plugin, makes
> that pretty clear...
>
> Cheers,
>
> -dr
>
> P.S. I do empathize with the fact that changing IDs where it /could/ not
> be necessary sucks; this is why LV2 has symbols which are the ID for a
> port instead. However, LADSPA is LADSPA, and doing what you are
> proposing is going to cause real headaches for real people, and would be
> remarkably unskillful given the feedback in this thread... pleas

Re: [LAD] Permafrost guitar amp, was Re: RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Tim E. Real]

On March 5, 2011 02:22:52 pm Dominique Michel wrote:
> Le Sat, 5 Mar 2011 18:55:19 +0100,
>
> Giuseppe Zompatori  a écrit :
> > From: Stefano D'Angelo 
> > Date: 2011/2/27
> > Subject: Re: [LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution
> > Reverb To: Giuseppe Zompatori 
> > Cc: linux-audio-dev@lists.linuxaudio.org
> >
> > 2011/2/27 Stefano D'Angelo :
> > > Ciao Giuseppe,
> >
> > Ciao Stefano,
> > Taking this email to a new thread.
> >
> > >Well... they seem to have a lot of stuff there. :-)
> > >
> > >However, I wonder how they do it... I think they are probably using
> > >some black box modeling, since multiple nonlinearities+feedback in a
> > >single system is very hard to model.
> >
> > They are very silent on this sadly, don't know what they are doing.
> >
> > >The kind of stuff I'm trying to do is accurately model a class A amp
> > >with a single triode using white box techniques... to give you an
> > >idea of what it sounds like see this:
> > >http://www.youtube.com/watch?v=cdNtmaIdLdo - it is part of my MSc
> > >thesis presentation (100.000 lire guitar, dated and slow laptop,
> > >cheap speaker and cheap camera... only the sound card is good).
> > >
> > >I guess you speak Italian (at least your name suggests that), so
> > >enjoy my weird southern accent. :-P
> >
> > Very interesting, I tried compiling your thesis with permafrost to try
> > this out (obtaining the source from the pdf has been hell BTW) but it
> > bails with an "m_pi" undeclared input/output function...
> >
> > Anyway, are you limited to the simulation of a half triode with white
> > box techniques? I think you should model at least both halves of a
> > triode if you're after accuracy, a single triode amplifier won't even
> > work in real life (I build tube amps, I know) ;)
> > Also class A amplifiers aren't very popular amongst guitar players
> > (mainly because of their clipping behavior). You also want a
> > multi-stage preamp with different filtering/biasing points between
> > stages.
> > You might think I am crazy but that's what you'll discover yourself by
> > observing schematics to popular guitar amps.
> >
> > Here's a simple (early Fender-like) amp topology:
> >
> >  Tube n. 1
> >  ---
> > Tube n. 2   Tube n. 3 and
> > 4
> >
> >
> >
> > 1st triode -> Tone stack -> post tone stack recovery triode -> P.I.
> > (Phase inverter) triodes -> (at least 2) Pentodes -> O.T. (Output
> > Transformer) -> Speakers
> >
> > ^
> >   ^
> >
> >
> >
> >
> >Presence
> > pot >-
> >
> >
> > This is the easiest PP (Push Pull) class A/B amp I could come up with
> > (sounds pretty darn good in real life). It has got a tone stack, 4
> > tubes (2 triodes and two pentodes) and an OT/speakers, do you think
> > this is feasible computational-wise with permafrost?
>
> With triodes, the preamp will include at least 2 stages (like the 2
> valves of an ECC81). With pentodes, you get higher gain and can make a
> complete guitar amp with 2 tubes like in the Fender Champ :
> http://www.drtube.com/schematics/fender/champ-5c1-schem.gif
>
> Also, be aware that each manufacturer make compromise between the sound
> quality and the manufacturing costs. As example, a well-know mark is
> using cheap power transformers, and when at full volume, the sound will
> be very bad because half of the distortion you will ear is due to
> saturation into the power transformer. As a consequence, those
> amplifiers are widely used by jazz musicians but almost never by rock
> musicians. The laters will also often blow the power transformers.
>
> Another well-know mark is using good but small output transformers, as
> well than better power transformers than the precedent one. The
> consequence is than the sound is very good at full volume, but a rock
> or blues musician will often blow the output transformers.
>
> Generally speaking, a common source of non linearities, and often
> ignored, is due to a non adequate driver stage. Tubes are by design
> made to work best at high impedance. To get a low output impedance,
> you need a transformer. But that's expensive hardware, especially in
> class A. Preamp and driver stages are class A stage, when the output
> stage is generally a class AB2 push-pull where the grid can become
> positive in respect to the cathode.
>
> Common tubes for such a push-pull are 6L6. According to the datasheets,
> such tube can take 0.35 watts and the driver output impedance must be
> lower than 500 ohms:
> http://www.mif.pg.gda.pl/homepages/frank/sheets/021/6/6L6.pdf
>
> It is no one single guitar amp I know on the market with a driver stage
> that can provide such a power to the output stage, and this is a major
> source of non lin

Re: [LAD] Attribution for Community Approval

[Tim E. Real]

On January 28, 2011 08:06:18 pm you wrote:
> On Sat, Jan 29, 2011 at 2:43 AM, Tim E. Real  wrote:
> > On January 27, 2011 04:35:47 pm Christopher Cherrett wrote:
> >> Could the community please review the attribution so we may continue
> >> with our journey? This attribution appears on the website, github,
> >> README and anywhere else you guys need to see it.
> >
> > From the GPL section 5:
> > a) The work must carry prominent notices stating that you modified it,
> > and giving a relevant date.
> >
> > I still don't see anything in the about box or the oo website mentioning
> > this. And as was mentioned here, you cannot claim sole copyright.
> >
> > Is this what you call attribution? Erasing every last mention of muse,
> >  even in comments?
> >
> > I received permission from Josh, the Fluidsynth and Swami author, to use
> >  the fluidsynth logo, on condition of attribution in AUTHORS, where I
> > added his name.
> > But you have removed his name from AUTHORS. That is wrong.
> >
> > I'm sorry but "Special Thanks to the MusE developers" in the AUTHORS
> >  doesn't cut it. It sounds like we simply helped with a module or
> > something.
> >
> > Browsing, you removed my name and stamp from the top of at least one
> > file: README.effects-rack, and put your name there.
> > If I understand the GPL, you are not to remove such attributions,
> > anywhere. Yes Alex, *I* wrote that several hundred word essay, not *you*
> > ,on how to use the effects rack. That was after I spent 2 weeks fixing
> > the rack.
> >
> > Do you know who has contributed much of the thousands of lines in
> >  the MusE ChangeLog over the past five years? Me.
> > But you wouldn't know that since you completely removed the ChangeLog.
> > So again, you have removed *many* attributions there, mine and many
> > others who worked on MusE. I would never do that.
> >
> > What is this shining piece of software you 'professionals' make?
> > Where can I buy a copy so I can call you up the same day, and tell you,
> >  quote, "it sucks", and demand changes, and you will do it the same day,
> >  for free? Really, I'd like to know. Please tell me what it is.
> >
> > Yes, only you know how software should be. Let us all bow down and do
> > things your way.
> >
> > I try very hard to accommodate all requests.
> > But a group of developers pestering me to fix dozens
> >  of things within mere hours or days due to some 'urgency', is sick.
> > Not one single patch contributed to us. Nothing.
> > Why don't YOU spend five years of your lives learning the code?
> >
> > Do you care that I just finished the soloing system, as you requested?
> > I clearly marked all changes to help you guys, even after the fork.
> >
> > BTW You owe Orcan so much gratitude.
> > He personally converted many thousands of lines of MusE code and UIs to
> > Qt4, while you guys lurked on the side waiting for us to finish.
> > Without him, OOM2 and MusE2 are nothing.
> >
> > Tim.
>
> Attribution has been added as requested.
>
> We'll add the history attribution in the about box as soon as we have
> the chance.
>
> The lurking insinuation is nonsense and you know it. We didn't
> "pester" you fix things, we were willing to do it ourselves, but you
> said no, more than once, as you wanted to do it yourself, as only you
> could do it, or at least that's what you told us.
Nope. Shall I dig up the logs where the whole lot of you kept coming at me? 
One request after another as I tried to cope.
Do it yourselves? Nope. You asked me to do much of the stuff.
But you didn't understand the work involved, the can of coding worms that 
 it was opening. Why didn't you go ahead and do it and give us patches?
I asked, and nothing.

> I didn't change the Readme as a direct challenge to you, it was a
> mistake on my part, and i noted the date in case there was a problem.
> Why would i do this knowing you'd be waiting in the wings to jump and
> find something wrong?
>
> If you have the courage to do this in a mature fashion going forward,
> then let us know privately if we've missed anything else.
And if you had the courage to do this right, I would not have to defend 
 our work now. 

>
> We've added a changelog.muse to the git repo, and we'll reference it
> in the changelog. As a courtesy, we'll also add a reference to muse in
> the already maintained copyright section in each file.
>
> Is that suitable for you?
Yes this sounds good so fa

Re: [LAD] Attribution for Community Approval

[Tim E. Real]

On January 27, 2011 04:35:47 pm Christopher Cherrett wrote:
> Could the community please review the attribution so we may continue
> with our journey? This attribution appears on the website, github,
> README and anywhere else you guys need to see it.

>From the GPL section 5:
a) The work must carry prominent notices stating that you modified it, and 
 giving a relevant date.

I still don't see anything in the about box or the oo website mentioning this.
And as was mentioned here, you cannot claim sole copyright.

Is this what you call attribution? Erasing every last mention of muse, 
 even in comments?

I received permission from Josh, the Fluidsynth and Swami author, to use 
 the fluidsynth logo, on condition of attribution in AUTHORS, where I added 
 his name.
But you have removed his name from AUTHORS. That is wrong.

I'm sorry but "Special Thanks to the MusE developers" in the AUTHORS
 doesn't cut it. It sounds like we simply helped with a module or something.

Browsing, you removed my name and stamp from the top of at least one file:
 README.effects-rack, and put your name there.
If I understand the GPL, you are not to remove such attributions, anywhere.
Yes Alex, *I* wrote that several hundred word essay, not *you* ,on how
 to use the effects rack. That was after I spent 2 weeks fixing the rack.

Do you know who has contributed much of the thousands of lines in
 the MusE ChangeLog over the past five years? Me.
But you wouldn't know that since you completely removed the ChangeLog.
So again, you have removed *many* attributions there, mine and many others
 who worked on MusE. I would never do that.

What is this shining piece of software you 'professionals' make?
Where can I buy a copy so I can call you up the same day, and tell you,
 quote, "it sucks", and demand changes, and you will do it the same day,
 for free? Really, I'd like to know. Please tell me what it is.

Yes, only you know how software should be. Let us all bow down and do things 
 your way.

I try very hard to accommodate all requests.
But a group of developers pestering me to fix dozens 
 of things within mere hours or days due to some 'urgency', is sick.
Not one single patch contributed to us. Nothing.
Why don't YOU spend five years of your lives learning the code?

Do you care that I just finished the soloing system, as you requested?
I clearly marked all changes to help you guys, even after the fork.

BTW You owe Orcan so much gratitude.
He personally converted many thousands of lines of MusE code and UIs to Qt4,
 while you guys lurked on the side waiting for us to finish.
Without him, OOM2 and MusE2 are nothing. 

Tim.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] DX7 (was Re: On the last eve of the year)

[Tim E. Real]

On January 2, 2011 05:13:22 pm Tim E. Real wrote:
> Hello. Not sure where to break in here, but the MusE sequencer
>  has a nice DX7 emulator called Deicsonze.
> It has adjustable parameter graphs and so on.
> In the new MusE-2 Qt4, it was updated to a much better version.
>
> However it is an internal MESS soft synth, so can't be used externally,
>  but as a workaround, MusE itself could possibly be used as the module.
>
> Hope that helps.
> Tim.

Sorry, just checked, it's actually a DX11/TX81Z emulator.
Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] DX7 (was Re: On the last eve of the year)

[Tim E. Real]

On December 31, 2010 06:08:04 pm Paul Giblock wrote:
> Now I wish I never sold my DX7 while I was short on cash in college..
>
> -Paul
>
> On Fri, Dec 31, 2010 at 12:11 PM, Julien Claassen  wrote:
> > Yes, there was a great collection, which I have downloaded at the time,
> > even before I knew hexter and before I could upload sounds to my DX7.
> > Marvellous what you can get and the pure mass of them! I think there was
> > one zip files with 10.000 patches in all.
> >  Keep hextering and dx7-ing on :-)
> >  Julien
> >
> > 
> > Music was my first love and it will be my last (John Miles)

Hello. Not sure where to break in here, but the MusE sequencer
 has a nice DX7 emulator called Deicsonze.
It has adjustable parameter graphs and so on.
In the new MusE-2 Qt4, it was updated to a much better version.

However it is an internal MESS soft synth, so can't be used externally,
 but as a workaround, MusE itself could possibly be used as the module.

Hope that helps.
Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] Richard Stallman warns against ChromeOS

[Tim E. Real]

On December 16, 2010 05:39:21 pm you wrote:
> On Thu, 2010-12-16 at 14:25 -0800, Dan Kegel wrote:
> > On Thu, Dec 16, 2010 at 12:41 PM, Tim E. Real  wrote:
> > >> The amiga is actually fairly late model here folks, I started with a
> > >> quest super elf I built from a kit.  Circa '77.
> > >
> > > 1802 CPU fan here too. Mine was RCA COSMAC VIP 1802.
> > > Added 3 channel sound (Famous G.I. AY3- chip) and
> > >  colour graphics with T.I. 9918 chip, after read Circuit Cellar article
> > > on it. Oh what fun...
> >
> > My first system was, IIRC, an Intersil 6100 (single-chip pdp-8 clone)
> > that my Dad designed and I wire-wrapped.  It had a four digit LED
> > display and a keypad.  I wrote my first real-world-affecting
> > program on it by using a 74c06 as a speaker driver, controlling it
> > with a single bit, and then flipping that bit with a hand-coded loop
> > to make all kinds of sirens.  Good times!
> > - Dan
>
> Aaargh, I had an amp from an established company, can't remember
> this company, everything was connected by wire-wrapping, so indeed a
> good discrete circuit, but the wire-wrapping did cause defects. Btw. I
> prefer good old leaded solder, but leaded solder in Germany isn't
> allowed anymore. We should start to wire-wrap all electronic devices for
> our politicians here :p.
>
> Cheers!
>
> Ralf

Yeah, the trouble with lead-free solder is that EVERY joint looks cloudy
 cold and bad, even if it's good. Very hard to tell if it's a good joint.
A bit frustrating from technician viewpoint.
Different type of product as well. Choose carefully.
When repairing, Mfr A says use this type, Mfr B says use that type.
Leaded solder still available here, but can't be used in new products.

If all else fails, use chewing gum and wrappers, like McGyver!

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] Richard Stallman warns against ChromeOS

[Tim E. Real]

On December 15, 2010 11:49:03 pm gene heskett wrote:
> On Wednesday, December 15, 2010 11:44:41 pm Ralf Mardorf did opine:
> > On Wed, 2010-12-15 at 17:42 -0500, gene heskett wrote:
> > > history being written by the winners, so the whole thing may have
> > > been white washed to a high polish by now.
> >
> > People who put their telephone handset into a thingy to be able to do
> > data telecommunication, before there was the Internet for public, tend
> > to be more sceptic/paranoid than youngsters ;).
>
> Never did that.  My first modem was a 120 baud device, but it was wired.
> Hooked up to the precursor to the coco3 I'm running right now, in the
> basement, logged into it over a serial port using minicom on this linux
> box.
>
> > The reason for this is,
> > that at that time, we might be hackers our self. I guess we can't
> > compare the easy hacking that was possible at C64 times (or Amiga ;),
> > with today data protection :D.
>
> The amiga is actually fairly late model here folks, I started with a quest
> super elf I built from a kit.  Circa '77.

1802 CPU fan here too. Mine was RCA COSMAC VIP 1802.
Added 3 channel sound (Famous G.I. AY3- chip) and
 colour graphics with T.I. 9918 chip, after read Circuit Cellar article on it. 
Oh what fun...

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [OT] Richard Stallman warns against ChromeOS

[Tim E. Real]

On December 14, 2010 10:04:10 pm Ralf Mardorf wrote:
> On Wed, 2010-12-15 at 02:47 +, Harry Van Haaren wrote:
> > On Wed, Dec 15, 2010 at 2:40 AM, Ralf Mardorf
> >  wrote:
> > A lot of people do, but perhaps they do it for mails that
> > anyway are in
> > public, e.g. to correspond to mailing lists.
> >
> > Anybody know of a public email provider that is better? Or more so:
> > that can prove they are better?
> > Open to suggestions :-)
> >
> > -Harry
>
> An evasive answer: For a while I used OpenPGP for emails ;). Perhaps all
> autistics and savants able to do prime factorization are only working
> for Google and no other provider or even intelligence services :D.
>

Ha. Good one.

But really, should we all be using some form of it?
I did for a while. I notice some folks here use it, some don't.
KMail always says unknown (I think we have to share keys).
Would it be better for LAD? Does it matter? 
Will it, soon, the way things are going?

Big brother is the corporations. 
I used to be able to claim a prize in a bag of potato chips by walking in 
 to any store and handing over a ticket. Now I must 'register' on-line.

This technology we use is a delicate dance between convenience and security, 
 but I don't like what I'm seeing transpire these days...

Here, our gov created a national "do not call" list, which we could join 
 and telemarketers would not be allowed to call us, if we said so.
People flocked to the list!
Then the gov sold the list to some marketing group. Ugh...

Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] envy24control, resp. it's successor

[Tim E. Real]

(Repost, I replied to our MusE list!)

On December 14, 2010 06:47:31 am David Santamauro wrote:
> Hi Niels,
>
>
> On Mon, 13 Sep 2010 17:36:11 -0700
>
> Niels Mayer  wrote:
> > On Mon, Sep 13, 2010 at 2:25 PM, Ralf Mardorf
> >
> >  wrote:
> > >Pardon, I didn't follow the progress of envy24control. Did you finish
> > > the recently development and if so, where can we/I get the latest
> > > source code?
> >
> > http:// mudita24.googlecode.com
> >
> > Status: still at 1.03. Waiting for Tim E. Real to commit and then will
> > release 1.04. Or use Tim's current patches (see link above).

I apologize, haven't had any time to complete the work.
I did quietly commit once more later on I think (I hope?), un-announced.
Its current state is my current state, there's nothing new to add right now.

I was so worried that changing from hard-coded slider min/max 
 and scale markings, to values obtained from asking ALSA, was the
 right thing to do. I felt it was, to support different, unknown, perhaps 
 yet-to-be-sold cards. 

We had good discussions on the list about the issues and where
 it could go from here. Everyone contributed good points and
 a good understanding of its shortcomings and issues.
 
Neils pointed out there's still some things to take care before we move on
 like some spacing issues, and of course we must deal with the
 meters, db markings, and slider height lining up correctly.

Fons pointed out his card gives him an extra button below the first slider,
 for adjustable hardware input level, which kind of ruined the uniform look
 of the sliders.
 
It works fine as is I think, but yeah, must continue with work on it.

> >
> > Niels
> > http://nielsmayer.com
>
> ...quick question on the "Monitor PCMs" tab: Why are there 2 sliders
> per PCM out? Shouldn't L/R Gang join channels 1 & 2, 3 & 4 etc...
>
Oh, is the gang not working? It was last I checked.
Oh wait, maybe I see what you mean, replace the two sliders with only one, 
 when gang is on?
We talked about replacing this with a pan knob or slider, like the 
 Windows version.

So many good ideas came out, a good vision of what it could be,
 but it takes time to implement them.

Tim.


---

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Musescore "music trainer"?

[Tim E. Real]

On November 12, 2010 12:48:47 pm Ralf Mardorf wrote:
> On Fri, 2010-11-12 at 18:32 +0100, Dominique Michel wrote:
> > Le Fri, 12 Nov 2010 00:54:58 -0500,
> >
> > "Tim E. Real"  a écrit :
> > > On November 11, 2010 11:06:10 pm Dominique Michel wrote:
> > > > Le Thu, 11 Nov 2010 16:43:41 -0300,
> > > >
> > > > Camilo Polymeris  a écrit :
> > > > > >> For me, a stand alone pitch detection application would be
> > > > > >> better :
> > > > > >>
> > > > > >> audio in -> pitch detect -> midi out
> > > > > >>
> > > > > >> You plug the instrument into the audio in, connect the midi
> > > > > >> out to any midi in in qjackctl, and it is just to play some
> > > > > >> melody.
> > > > > >>
> > > > > >> Ciao,
> > > > > >> Dominique
> > > > > >
> > > > > > There is aubionotes (http://aubio.org/aubionotes.html), which
> > > > > > claims to do exactly what you want. Don't know how well,
> > > > > > though. I am trying to connect it to PianoBooster, to see if
> > > > > > that could be a solution. WaoN could also be an option, I'll
> > > > > > try that next. Eventually, I'd like an integrated app.
> > > > > >
> > > > > > Greetings,
> > > > > > Camilo
> > > >
> > > > Thanks for the tip !
> > > >
> > > > > Ok. If someone is interested: I can report that aubionotes works
> > > > > quite well for the samples I tried (brass mostly, all
> > > > > monophonic). WaoN is similar, maybe even better, but doesn't work
> > > > > realtime, it handles pre-recorded samples, only.
> > > >
> > > > Same thing here. I think that it must use some kind of fft. The
> > > > problem with fft and realtime is not the processing power but the
> > > > time it take before you get a sufficient amount of samples in order
> > > > to be able to run the fft.
> > > >
> > > > Ciao,
> > > > Dominique
> > >
> > > Exactly. I was going to start a thread asking about this. Mind if I
> > > pitch in? Difference between lowest note on a guitar and next note is
> > > very small, requiring large number of FFT bins. (If you play a flute,
> > > you're lucky.) You can put a crappy time domain style pitch shifter
> > > ahead of the converter to reduce this. (A good freq domain PS may
> > > have more latency.) It's fun. With practice a normal guitar becomes a
> > > piano etc...
> > >
> > > I've seen polyphonic products advertised claiming zero or near zero
> > > latency. How do they do it?
> >
> > I don't know. If you take a guitar synthesizer, it have a polyphonic
> > mic, that is one mic per cord (similar to a simple humbucking per note).
> > They certainly make 6 monophonic note extractions.
Yes, there are guitar synthesizer kits, which use a multi pickup with
 six individual outputs. Some come complete with a special guitar.
Having multi pickup with six individual outputs is certainly the best way.
Then you only need six easy mono synthesizers.
But what I am talking about is using a normal guitar with a normal
 pickup, and using FFTs to make a polyphonic converter.
It works, but of course it's far from perfect.

> >
> > Guitar mics take in account only the vertical movements of the cords,
> > the output signal is the derivative of this movement.
> >
> > Also, the harmonic content of a guitar note is not constant. During the
> > attack, the value of the fundamental is the most important signal in
> > the note, but during the sustain, the value of the fundamental decrease
> > very fast and the second harmonic become the highest tone in the note.
> > It is even more complicated when the cord touch the frets because you
> > will get false maximums of the signal. You can also get hum with a
> > simple humbucking, and you will get saturation with a double humbucking.
> >
> > > I've used FFT, but when told of this delay problem, my friend keeps
> > >  telling me no, use Laplace transforms. When I studied them (looong
> > > ago), I could not fully understand how to apply the knowledge.
> > > Is there a Laplace library out there?
> >
> > I am not sure, but the FFT is a particular case of the bipolar Laplace
> > transform

Re: [LAD] Musescore "music trainer"?

[Tim E. Real]

On November 11, 2010 11:06:10 pm Dominique Michel wrote:
> Le Thu, 11 Nov 2010 16:43:41 -0300,
>
> Camilo Polymeris  a écrit :
> > >> For me, a stand alone pitch detection application would be better :
> > >>
> > >> audio in -> pitch detect -> midi out
> > >>
> > >> You plug the instrument into the audio in, connect the midi out to
> > >> any midi in in qjackctl, and it is just to play some melody.
> > >>
> > >> Ciao,
> > >> Dominique
> > >
> > > There is aubionotes (http://aubio.org/aubionotes.html), which claims
> > > to do exactly what you want. Don't know how well, though. I am
> > > trying to connect it to PianoBooster, to see if that could be a
> > > solution. WaoN could also be an option, I'll try that next.
> > > Eventually, I'd like an integrated app.
> > >
> > > Greetings,
> > > Camilo
>
> Thanks for the tip !
>
> > Ok. If someone is interested: I can report that aubionotes works quite
> > well for the samples I tried (brass mostly, all monophonic). WaoN is
> > similar, maybe even better, but doesn't work realtime, it handles
> > pre-recorded samples, only.
>
> Same thing here. I think that it must use some kind of fft. The problem
> with fft and realtime is not the processing power but the time it take
> before you get a sufficient amount of samples in order to be able to run
> the fft.
>
> Ciao,
> Dominique

Exactly. I was going to start a thread asking about this. Mind if I pitch in?
Difference between lowest note on a guitar and next note is very small,
 requiring large number of FFT bins. (If you play a flute, you're lucky.)
You can put a crappy time domain style pitch shifter ahead of the 
 converter to reduce this. (A good freq domain PS may have more latency.) 
It's fun. With practice a normal guitar becomes a piano etc...

I've seen polyphonic products advertised claiming zero or near zero latency. 
How do they do it? 

I've used FFT, but when told of this delay problem, my friend keeps 
 telling me no, use Laplace transforms. When I studied them (looong ago),
 I could not fully understand how to apply the knowledge.
Is there a Laplace library out there?

Wavelets? I studied those as well, but my meagre brain could not cement.

To catch the higher notes first, how about n FFTs with n samplers driven by 
 n separate even-tempered clocks, where n is the desired number of notes? 
For ex. 3 octaves, 36 FFTs. I forget why, but I think that didn't work out. 
I think the pesky relation giving the delay kept getting in the way.
You increase the sample rate and you just end up increasing the delay
 because you need more freq bins for the same given resolution.
The delay is really governed by the smallest difference in notes you want 
 to detect. In guitar's case, I found it just passes as acceptable.

Tim.



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Faster context switch

[Tim E. Real]

On November 10, 2010 04:20:02 pm you wrote:
> On Wed, Nov 10, 2010 at 4:11 PM, Tim E. Real  wrote:
> > MusE already fully supported the old fst, so we've got code which I hope
> >  would put us ahead of the game.
>
> i don't believe that torben & i ever released the wine-as-a-library
> version of FST, so there effectively is no "old fst" in the sense that
> has been alluded to by michael.
>
> --p

That would be the old fst 0.6 (I think), just before the major changes. 
MusE used to work with fst as a library, up to that version. 
Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Musescore "music trainer"?

[Tim E. Real]

On November 10, 2010 03:40:01 pm Dominique Michel wrote:
> Le Wed, 10 Nov 2010 13:36:21 -0300,
>
> Camilo Polymeris  a écrit :
> > > maybe http://pianobooster.sourceforge.net/ is what you want ?
> >
> > Very interesting. Will try it as soon as possible. Piano/MIDI only
> > input, right? But maybe support for other instruments and pitch
> > detection can be added.
> >
> > Thanks,
> > Camilo
>
> For me, a stand alone pitch detection application would be better :
>
> audio in -> pitch detect -> midi out
>
> You plug the instrument into the audio in, connect the midi out to any midi
> in in qjackctl, and it is just to play some melody.
>
> Ciao,
> Dominique
>

I too am interested in pitch detection -> midi.
I want to make a polyphonic guitar to midi converter plugin.
I've done it before as a standalone app in Windows.

But my question is which linux plugin architectures support
 audio in + midi out?

I'm thinking DSSI, but the midi out would have to be an OSC control
 stream, am I correct?

Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Faster context switch

[Tim E. Real]

On November 10, 2010 01:58:55 pm you wrote:
> On Wed, Nov 10, 2010 at 1:48 PM, Tim E. Real  wrote:
> > Hi, thanks for this thread, I've been wanting to learn more
> >  about how we could use (the newer) fst in our MusE for example.
> > I was not sure how to make MusE a wine app, though, as I was told to do.
> >
> > Besides getting it to compile as a wine app, are there any major
> >  tasks, traps, and conversions to look out for in the rest of the app?
>
> there are zero changes to the rest of ardour when building it in this
> way. ardour's a pretty complicated app, so i think you can take that
> as a very likely "no".
>
> --p

That's encouraging. 
MusE already fully supported the old fst, so we've got code which I hope 
 would put us ahead of the game.

Thanks. Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Faster context switch

[Tim E. Real]

Hi, thanks for this thread, I've been wanting to learn more
 about how we could use (the newer) fst in our MusE for example.
I was not sure how to make MusE a wine app, though, as I was told to do.

Besides getting it to compile as a wine app, are there any major 
 tasks, traps, and conversions to look out for in the rest of the app?

Thanks. Tim.


On November 10, 2010 01:15:52 pm Michael Ost wrote:
> On 11/2/10 10:06 AM, Paul Davis wrote:
> > On Tue, Nov 2, 2010 at 12:53 PM, Michael Ost  
wrote:
> >> Hi list,
> >>
> >> I am seeing what appears to be a 4 - 7 usec context switch time on a 3
> >> GHz Core 2 Duo machine with the 2.6 kernel, and 10 - 15 usecs on a 1.66
> >> GHz Atom. Is that reasonable? Does anyone have any tips on how to speed
> >> that up, if possible?
>
> 
>
> >> Since this has to happen twice per buffer, at a 32 sample buffer size
> >> and with 10 VSTs, overhead accounts for about 14% of the CPU. On the
> >> slower Atom machine, it would account for 33% of the CPU.
> >
> > you can't reduce context switch times. the code involved is in the
> > kernel.
> >
> > it is precisely this problem that led to FST, and the more general use
> > of FST by ardour (for example) where rather than going back and forth
> > between wine and the linux app, the linux app becomes a wine process
> > itself, and everything is in-process.
>
> I asked Alexandre Julliard, the maintainer of the Wine project, about
> the libfst approach, and thought this list might be interested in his
> response.
>
> - Michael Ost
>
> First message (nov 8) when asked for a read on the libfst design he
> said, "They have a wineserver and everything, they just bypass the
> preloader and initial setup. It's a variant of the Mono patch. It should
> work OK as long as both the host Linux app and the Windows DLL are
> well-behaved and don't depend on things like memory layout, switching
> stacks, signals, starting Linux threads, etc."
>
> And here's the second message, an exchange where I (MO) asked him (AJ)
> for details about the above points:
>
> MO: "Memory layout" - is there any risk that a DLL might see a smaller
> VM size without the preloader? We are using the /3GB switch. Would that
> be at risk?
>
> AJ: It's not just size, but areas that are expected to be free that
> would be occupied, for instance the DLL load address, things like that.
>
> MO: "Switching stacks" - I can't see an audio DLL switching stacks.
> Sounds like something a debugger might do...?
>
> AJ: I know the jack library on Linux plays some strange games with the
> stack to try to reduce latency. I'd imagine an audio DLL might try to do
> stuff like that.
>
> MO: "Signals" - seems very unlikely for a hosted audio DLL
> "Starting Linux threads" - shouldn't happen from straight windows code.
>
> AJ: These two would be potential problems in the Linux host application,
> not in the DLL.
>
> MO: "Etc" - and what might this be? %)
>
> AJ: I'm sure there are other things, it's really hard to predict what
> unspecified code is going to do. Basically everything we do during
> startup was added because something depended on it, so anything that is
> bypassed is a potential problem. Whether it will be a problem in actual
> use can really only be determined by testing.
>
> MO: This is all in WINE/loader, right?
>
> AJ: Yes, but there's a lot of init code in ntdll too, particularly
> regarding memory layout (that code will still be executed with the
> libfst patch, but it may not be able to set things up the way it wants
> to when not run at process startup).

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] Qtractor 0.4.7 - The Furious Desertrix is out!

[Tim E. Real]

On October 1, 2010 06:55:52 pm Niels Mayer wrote:
> Also some of the configuration dialogs are coming up bigger than the
> screensize. So you have to Tab-down to the invisible "ok" or "cancel"
> and press return, and hope you got the right one. 
Just curious, doesn't your system respond to holding ALT down and moving 
 a window by grabbing anywhere in the window? Much easier than tabbing...

(Built QTractor and tested OK.)
Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ADAT digital audio receiver and transmitter circuit

[Tim E. Real]

On September 19, 2010 06:00:35 pm f...@kokkinizita.net wrote:
> On Sun, Sep 19, 2010 at 05:01:25PM -0400, Tim E. Real wrote:
> > Send it to me! I'll do it!
> > Replacing 100+ pins SM ICs by hand is something we specialized in every
> > day for many years in our repair shop.
> > When you can't afford high priced rework stations, you learn to do
> > without.
> >
> > A Sony technician taught us one method in our arsenal:
> > When soldering, just go nuts with soldering all the pins, don't worry
> > about bridges. Then you use solder wick to remove all the bridges. Then
> > do some fine touch-ups with the iron. This method worked quite well in
> > many cases. A fine dental pick or equivalent tool helps, to run in
> > between the pins as you are touching up with the iron.
>
> Good to know !
>
> When I was working at Alcatel there were some ladies in the
> electronics workshop specialised in this sort of operations -
> replacing SMD components, destroyed by the developers, on
> prototype PCBs. They could also solder cables onto 19-pin
> Lemo connectors without melting them, and perform other sorts
> of miracles. They won my eternal admiration - I get nervous
> when I have to solder an XLR-3M.
>
> Ciao,
He he. Yes, small things require a certain mechanical aptitude,
 steady hands, and sometimes nerves of steel.
Oh, and a good head-mounted magnifier.
Some folks just aren't comfortable and get very nervous.

Did you ever see that famous guy who crafts extremely small scenes
 inside the eye of a needle? (On YouTube). That's pressure!

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] ADAT digital audio receiver and transmitter circuit

[Tim E. Real]

On September 18, 2010 07:50:01 pm Niels Mayer wrote:
> Is there a mass-market (a cheap module from china/taiwan/hongkong)
> equivalent of the OptoRec and OptoGen , which could be usefully hooked
> up to a few of these:
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=230418195291
> to make a useful multichannel D/A for an ADAT lightpipe ; the optorec
> could likewise be paired with external A/D's or used to "vampire" an
> I2S signal from external digital gear w/o digital outputs.
>
> Also, experience with assembling and/or using the OpenRec/OptoGen?
>
> http://electronics.dantimax.dk/Kits/Digital_audio/11329401182.html
> ..
> OptoRec and OptoGen
>
> ADAT digital audio receiver and transmitter circuit
>
> These kits is [sic] an 8-channel interface circuit using the ADAT
> protocol. They supports the sample rates 44.1 and 48kHz and up to 24
> bits.
>
> The boards can be used for adding an ADAT input to a DAC, an ADAT
> output to an ADC or for DIY projects. The receiver board includes an
> ADAT input, ADAT output, a wordclock input and I2S outputs. The
> transmitter board includes an ADAT output and I2S inputs.
>
> The kits use SMD parts, so some SMD experience may be needed to
> assemble the board. SOT-23-5 parts are used, so a fine-tipped
> soldering iron (or SMD tools) is needed.
> ..
>
> It's that "SMD experience"  needed part that really gets me. I will
> invariably get a blob of solder bridging two SMD pins, and then in the
> course of trying to correct my mistake manage to get it bridging a few
> more pins and melting the ic or lifting the pad of the pc board.
> there's a reason i went into software. The undo key.
Send it to me! I'll do it!
Replacing 100+ pins SM ICs by hand is something we specialized in every day
 for many years in our repair shop.
When you can't afford high priced rework stations, you learn to do without.

A Sony technician taught us one method in our arsenal:
When soldering, just go nuts with soldering all the pins, don't worry about
 bridges. Then you use solder wick to remove all the bridges. Then
 do some fine touch-ups with the iron. This method worked quite well in 
 many cases. A fine dental pick or equivalent tool helps, to run in between the 
 pins as you are touching up with the iron.

Tim.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Mouse/knob interaction

[Tim E. Real]

On September 7, 2010 02:20:10 pm Gordon JC Pearce wrote:
> This is going to stir up a bit of discussion!
>
> Rotary knob GUI elements - should you move the mouse in a circle to
> operate them, or up and down?  What about side to side?
>
> Gordon MM0YEQ
>

A quick check of our MusE knobs shows it's circular motion.

Circular or linear doesn't really bother me too much,
 but if linear, then both up/down AND left/right should 
 operate the knob. I've seen some that do one but not the other.

However, I would like to share with you a 'patented' (he he) 
 technique I developed a long time ago:

When the mouse cursor goes to the edge of the screen you
 have no more movement, forcing you to pick up the mouse
 and go back to another position away from the screen edge
 and continue adjusting.

So here's what you do in the coding: 
When the control is clicked, you turn off the mouse cursor so that
 it is always INVISIBLE during adjustment, then you force it to the 
 CENTRE of the screen, and wait for some mouse movement.
When movement happens, you record how much it moved (delta)
 and use that to adjust the control's value (as usual), and then you 
 FORCE the mouse cursor right back to the CENTRE of the screen again,
 waiting for more mouse movement, and the whole process repeats.
Then when the control is un-clicked, you force the mouse cursor
 back to where it originally would have been, and turn it on again 
 so it's visible.

This way the mouse NEVER reaches the edge of the screen during 
 adjustment, although it may physically reach the edge of your desk.
However, with trackball mice you can keep on rolling and rolling, and
 the control keeps adjusting without end !

I used this technique in a 'spinbox' derivative which I call 'RollEdit'.
I hate rally tiny spinbox up/down arrows, and waiting for them 
 to increment, don't you?
With my 'RollEdit', you simply click anywhere in the edit portion
 and start rolling, and rolling, and rolling, and the value keeps
 going and going and going... No mouse repositioning needed.

I also used it in 3D modelling apps: You click anywhere in a 'scene'
 and start rolling, and the zoom or viewer position (for example) 
 just keeps going and going. No visible mouse cursor to get in the way.
Excellent with trackballs !

(AutoDesk's 3D Studio at one time came close to this, but they
 messed it up by leaving the mouse cursor visible and making
 it 'wrap around' the edges of the screen. Like the game Asteroids, 
 very annoying.)

All of that work was in Windows and it was very complicated because
 you can receive multiple mouse movement messages for just one
 movement.

I've always wondered if Linux would be able to handle this technique
 better than in Windows. Never investigated yet. Opinions?

In MusE, when you click on any slider, even in the slider trough area,
 the mouse cursor is FORCED to the centre of the slider knob. 
I did this to help with automation, so that you could easily 'grab' the 
 slider knob even while it was in fast motion due to existing automation 
 movements.

Gotta go! Looks like bad thunderstorm here!

Thanks. Tim.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards

[Tim E. Real]

On August 10, 2010 11:09:30 pm Tim E. Real wrote:
> Again, per-strip post-fader metering, I tells ya' !

Making slider minimum -60dB or -144dB, and how to make meter same height
 (as discussed down the threads):
Post-fader metering buttons would be an answer there as well.

It gives us the perfect excuse, and the mechanism, to make the meters go 
 all the way down past -144dB if we want - and thus be the same height as 
 the sliders no matter if their minimum is -60dB, -144dB...
The mechanism beingpost-fader peak = pre-fader peak + attenuation dB 
 which facilitates a longer meter, right?
(Could even say demands it, but the meters could end up longer than sliders!
 So we chop them off at the min slider value.) 

We give the user AFM buttons and three runtime options: 
 1: Meter and slider minimum are both ~-48dB before off.
 2: Meter and slider minimum are both ~-60dB before off.
 3: Meter and slider minimum are both ~-144dB before off.

Again, the meters would have to be split into L/R when AFM is on (ugh!).

The master meters would remain the same at -48dB min.
(There's no master level controls to add their attenuation to the meters.)

One unsightly thing would be that with AFM off (or slider near 0dB), 
 the entire meter section below -48dB comes on at once, and we're
 sort of back at square one - too much space. 
Oh well, but at least there's the potential to actually use the space.
How else can we solve it? It'll look bad with short meters fixed at min -48dB.

Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards

[Tim E. Real]

On August 17, 2010 08:53:46 pm you wrote:
> On Tue, Aug 17, 2010 at 3:25 PM, Tim E. Real  wrote:
> > Try my patches. See AUTHORS for changes and TODOs.
> > Once again set up a fresh mudita24-1.0.3 folder and apply these patches.
>
> So I applied the patches (
> http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100817/
>d02f8aaa/attachment.bin ) 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.
I found out the GtkScale "digits" property, which automatically rounds all 
 values to the chosen number of places, does not work unless the 
 value readout is enabled. IMO this is broken, it should work always.
Also GtkScale doesn't properly size its own label when the label is at top 
 or bottom. Text becomes chopped off or spills pixels into a neighbouring 
 widget. 

So, a related TODO I forgot to mention, which would have been the solution 
 to the above sizing problem (had we used GtkScale's own label), 
 is this:

We want to grab the width of a worst-case string like +88.88 (I guess simply 
 by asking pango) before creating all the labels (or after a theme change). 
Then, add a single "size-request" handler for all the labels and make sure 
 they *never* alter from this worst-case width (+ a few border pixels).
That should keep everything fixed in place.

>
> > Let me know if you want them in another form, applied to some later
> >  version or something.
>
> Nope, I've been waiting on your changes and doing other things.
>
> > I have not touched the meters or slider ranges yet.
> > But I think I have accomplished what I primarily set out to do, which is
> >  have slider markings and make them, and the analog slider min/max,
> >  depend on ALSA, to support different codec chip(s).
> > *** That is the part which needs testing by all of you with various cards
> > !
>
> I will test the Terratec DMX6fire next...
Now I'm wondering what happens if the analog ALSA control names change.
Would different codecs have different control names?
Maybe that's why that card you mentioned before didn't have an analog page? 
Was it worth my effort, to ask ALSA for the ranges to set the analog 
 sliders/markings instead of hard-coding them? Was my assumption that 
 different codec chips might have different ranges correct? We'll see...

>
> > Observe the analog slider markings/stepping and let me know of any
> > problems.
>
> 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.
Ah, yes, possibly the marker drawing area is not fully collapsing
 with no markers, will check. I forgot to look at this and ensure
 it can go to zero width, or else don't create it at all, with no markings...

>
> I also notice that in 1.03, I forgot to add verbiage for the  "-g" (
> --channel_group_modulus )option to the --help output.
>
> > I couldn't figure out a way to make the mouse wheel snap to the markers,
> >  wheel gives the same scroll type as moving the slider: GTK_SCROLL_JUMP.
>
> 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."
The wheel seems to move by 3dB whereas the keys move it by 1.5dB.
That GTK_SCROLL_JUMP thing stopped me in my tracks.
Hopefully there's a style property or something...

>
> > There may well be a few fix

Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards

[Tim E. Real]

Hello list, Niels. 

Try my patches. See AUTHORS for changes and TODOs.
Once again set up a fresh mudita24-1.0.3 folder and apply these patches.
(Do not apply my last patches.)
Let me know if you want them in another form, applied to some later
 version or something.

I have not touched the meters or slider ranges yet.
But I think I have accomplished what I primarily set out to do, which is 
 have slider markings and make them, and the analog slider min/max,
 depend on ALSA, to support different codec chip(s).
*** That is the part which needs testing by all of you with various cards !
Observe the analog slider markings/stepping and let me know of any problems.

Users with Gtk+ 2.6 or higher get the full benefit of GtkRange's 
 "change-value" signal. 
Users without 2.6 miss the slider snapping to integers, and slider trough
 paging marker snapping, but still get the KB page up/down snapping.

I couldn't figure out a way to make the mouse wheel snap to the markers, 
 wheel gives the same scroll type as moving the slider: GTK_SCROLL_JUMP.

There may well be a few fixes and tweaks later, but I think this is how 
 I wanted it to be so far. Hopefully we can now move forward with other
 items discussed.

Devels: Note that if we wish to remove some of the marker texts later 
 to reduce clutter, please keep the actual marks, as this is now what the
 sliders snap to (unless there are no markings at all, or they're turned off, 
 in which case it uses the sliders' own page increment values.)

Eagerly awaiting responses... Tim.




mudita24-1.0.3-patches-2.tar.gz
Description: application/compressed-tar
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards

[Tim E. Real]

On August 12, 2010 07:57:10 pm Tim E. Real wrote:
> I discovered the magic bullet I was looking for:
> The GtkRange::round_digits member !
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.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards

[Tim E. Real]

Humming along here, Niels I got your request done, click on a scale and
 the corresponding slider gets the focus.
Much code cleanup, rewrites, removed my 2.14 dependencies.
Found some code, before we came along, which had those deps as well.
Specifically the GTKAdjustment->value property is new since 2.4
 so I changed all of lines, and mine as well.
It means envy24control couldn't possibly have compiled with gtk 1.x could it?
I feel a bit better about us doing these 2.x things now.

About the slider fractional values problem:
I discovered the magic bullet I was looking for: 
The GtkRange::round_digits member !
I set it to zero for all the sliders and presto ! Now the sliders output
 only integer values. There's no in-between fractional stops now.
This means the sliders now 'quantize', or 'snap', to each integer value.
That's with mouse, mouse wheel, or KB. 
Man, if I had only known this before...
I can't find much info on how old that member is but it seems to date back
 to at least 2005. It's a 'protected' member and not well doc'd.

On August 11, 2010 03:26:19 pm you wrote:
> On Tue, Aug 10, 2010 at 11:24 AM, Tim E. Real  wrote:
> > 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.
>
> 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.
Yes I saw that comment and code in there. I was going to post 
 "Ah yes, manipulate the drawing, not the widget height".
That means, as you say, maybe stretching the bottom or top end
 or something. It's a tough problem to solve. 

> 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  wrote:
> > But you ultimately turn to the analog volume tab in order to
> >  affect what's arriving at the meters and the faders.
>
> 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. 
I knew those labels were there but their significance became
 clearer with these discussions. It means it is possible to add meters, right?

> 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.
>
> > If we put a pre/post fader button on each digital mixer strip,
> >  then in post mode the user would have to understand that
> >  what is shown on the meter is affected by the sum of the
> >  digital mixer slider level and some corresponding analog slider level.
> > That is what is ultimately feeding the mixer after the fader, isn't it?
> > So this information would be useful to show, wouldn't it?
> > It is readily 'available', am I correct?:
> >  post-fader meter value = pre-fader meter dB value + slider dB value
>
> 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 app

Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards

[Tim E. Real]

On August 10, 2010 10:08:51 am you wrote:
> On Tue, Aug 10, 2010 at 1:14 AM,   wrote:
> > - The meters are there to show levels at the AD/DA converters,
> >  i.e. to allow you to check you are using those in a sensible
> >  way. They happen to be on the same window as the mixer, which
> >  can be useful as they suggest to the user which signal is
> >  being controlled by a fader. 
But you ultimately turn to the analog volume tab in order to 
 affect what's arriving at the meters and the faders.
If we put a pre/post fader button on each digital mixer strip,
 then in post mode the user would have to understand that 
 what is shown on the meter is affected by the sum of the 
 digital mixer slider level and some corresponding analog slider level.
That is what is ultimately feeding the mixer after the fader, isn't it?
So this information would be useful to show, wouldn't it?
It is readily 'available', am I correct?:
 post-fader meter value = pre-fader meter dB value + slider dB value  

However I realised yesterday that each digital mixer strip is STEREO.
That means for post-fader metering, we would need to split the current
 single meter into two meters - left and right.

If we couple this with MONO analog volume meters, and each of
 THEM with pre/post buttons, AND to combat clutter we split
 the DAC/ADC tab into two (he ducks, expecting projectiles)
 or use Niels' suggestions below ...

OK, I know there's issues, I must first understand how the routing 
 affects all of this. It's only ideas for now.
It just seems like something is missing, like it really could use
 some kind of extra metering + options, you know?

> >  But otherwise they are not part
> >  of the mixer, and a better place for them would be with the
> >  HW gain controls.

>
> 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.
>
> > - The post-fader signals in the mixer are not available anywhere,
> >  they just get summed to the bus.
>
> 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".
Another good idea. And Pinocchio said,  "I'm a real mixer, I'm a real mixer!". 

Again, per-strip post-fader metering, I tells ya' !
Cheers. Tim.

>
> -- Niels
> http://nielsmayer.com

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards

[Tim E. Real]

On August 10, 2010 10:06:17 am you wrote:
> Just applied the patches, compiled... AWESOME! Sliders, dB scales and
> meters in "Monitor Inputs" and "Monitor PCMs" resize when the window
> is stretched! I'm looking forward to the completion of your TODO items
> in AUTHORS esp the digital mixer meter resizing with stretchy scales
> just like the mixer's channel meters. Let me know when you have things
> finalized, and I'll add a mudita24 1.04 version to
> http://nielsmayer.com/envy24control/ .
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.

>
> Of course the new resizeability feature brings up the issue that the
> sliders can become long enough to display different positions for two
> sliders at the same attenuator dB value. Perhaps this could be
> remedied by an on-release callback that sets the slider back to the
> center of it's actual dbFS value, e.g. -1.5dB, -3.0, -4.5, -6.0 etc...
> This becomes especially noticeable on a stretched slider in "Monitor
> Inputs" or "Monitor PCMs" due to the 1.5dB steps provided by the 24bit
> attenuators feeding the digital mixer. It doesn't seem to be as
> noticeable with the 0.5dB steps in the "Analog Volumes" panel.
> However, on a fully-height-expanded window, you can notice, for
> example, two sliders of a stereo pair showing the same dB value but
> slightly different positions visually.

> One "regression" in your change: formerly, you could click within the
> scale/labeling area to set focus on a given slider. This is a large
> and easy-to-click area if you just want to set GUI focus to that
> particular channel and use the scroll-wheel or keyboard up/down arrows
> to change values). Because if you click in the slider area to set the
> selection, unless you click on the slider itself, the value gets
> changed.
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.

>
> > One more thing: Because of my use of gtk_adjustment_get_page_increment()
> >  and friends, which require gtk+ 2.14, I think it may be necessary to
> >  release this as a separate program than envy24control.
> > There may be people out there with old setups who need the old one.
> > The ALSA folks may not like replacing the old one with mudita24 for
> > that reason.
>
> Seems like there should be a way for their build system to handle
> skipping programs that use gtk2 if only gtk1 available ... at least
> for the myriad packages in
> alsa-tools "Specialist tools for ALSA" -- which might also be a
> perfectly appropriate place to put a latest-gtk2-using tool providing
> special control to a specific set of cards. I haven't surveyed the
> other packages to see what kind of dependencies they have... I'm
> CC'ing to alsa-devel in hopes of getting an answer on this.
> (thread summary:
> http://linuxaudio.org/mailarchive/lad/2010/8/8/172623
> http://linuxaudio.org/mailarchive/lad/2010/8/8/172629 )
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.

>
> Niels
> http://nielsmayer.com

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards

[Tim E. Real]

On August 9, 2010 08:53:21 pm Tim E. Real wrote:
> One more thing: Because of my use of gtk_adjustment_get_page_increment()
>  and friends, which require gtk+ 2.14, I think it may be necessary to
>  release this as a separate program than envy24control.
> There may be people out there with old setups who need the old one.
> The ALSA folks may not like replacing the old one with mudita24 for
>  that reason.
> Those newer functions are absolutely required for these new scale markings.
> Without them, I can't do it.
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.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards

[Tim E. Real]

On August 9, 2010 08:45:49 pm Tim E. Real wrote:
> Hey hey hey!
> Look what I've got...
>
> I thought it important and complete enough to let you see
>  where it is going.

One more thing: Because of my use of gtk_adjustment_get_page_increment()
 and friends, which require gtk+ 2.14, I think it may be necessary to
 release this as a separate program than envy24control.
There may be people out there with old setups who need the old one.
The ALSA folks may not like replacing the old one with mudita24 for
 that reason.

Those newer functions are absolutely required for these new scale markings.
Without them, I can't do it.
But at least it's a good step back from gtk 2.16, which is required for those 
 native GtkScale markings, which I've now replaced.

Tim.

>
> On August 8, 2010 04:08:01 pm Niels Mayer wrote:
> > I applied a variation of the suggestion made by Guido Scholz on LAD to
> > the autoconf files and put out a new release to solve the potentially
> > missing link to "-lm"
> >
> > http://nielsmayer.com/envy24control/mudita24-1.0.3.tar.gz
> > http://nielsmayer.com/envy24control/mudita24-1.0.3.x86_64.tgz
> > http://nielsmayer.com/envy24control/mudita24-envy24control-0.6-to-1.0.3.p
> >at ch
> >
> > While I was modifying configure.in,  I also got rid of the
> > command-line switch to allow Gtk1 building, which means file
> > 'configure.in-gtk1' is no longer needed.  So as to prevent needless
> > butchery of the former envy24control GIT directory, I left the file
> > alone
> >
> > Niels
> > http://nielsmayer.com
> >
> > PS: note that I symlinked the old 1.0.2 files to these new 1.0.3 files
> > to prevent people from picking up the version with the configuration
> > error pointed out by Geoff King.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [LAU] mudita24 1.02 -- improved envy24control mixer/router for ice1712-based sound-cards

[Tim E. Real]

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:
> I applied a variation of the suggestion made by Guido Scholz on LAD to
> the autoconf files and put out a new release to solve the potentially
> missing link to "-lm"
>
> http://nielsmayer.com/envy24control/mudita24-1.0.3.tar.gz
> http://nielsmayer.com/envy24control/mudita24-1.0.3.x86_64.tgz
> http://nielsmayer.com/envy24control/mudita24-envy24control-0.6-to-1.0.3.pat
>ch
>
> While I was modifying configure.in,  I also got rid of the
> command-line switch to allow Gtk1 building, which means file
> 'configure.in-gtk1' is no longer needed.  So as to prevent needless
> butchery of the former envy24control GIT directory, I left the file
> alone
>
> Niels
> http://nielsmayer.com
>
> PS: note that I symlinked the old 1.0.2 files to these new 1.0.3 files
> to prevent people from picking up the version with the configuration
> error pointed out by Geoff King.



mudita24-1.0.3-patches.tar.gz
Description: application/compressed-tar
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

Hi Niels.

Something odd. Are you sure about those digital mixer ranges?
They now go down to only -48dB instead of -144dB.
Seems like 2/3 of the range is missing?
Verified against the original mixer, and amixer.

Also, the 'active' colour of the meters seems way too 'soft'?
Seems like just a slightly darker grey shade than the meter
 background (although I know it's supposed to be blue).
This makes it very hard to see the meters in action.
A lighter shade of blue would make it look nice like a flourescent
 type of display.

--
Also, sorry about this, I missed something in the ALSA dB reading 
 code I submitted: The index of the control:

In volume.c: dac_volume_adjust() and adc_volume_adjust(),
 remove the clear() and set an index like this:

  snd_ctl_elem_id_t *elem_id;
  snd_ctl_elem_id_alloca(&elem_id);
  //snd_ctl_elem_id_clear(elem_id); // TER: Removed
  snd_ctl_elem_id_set_interface(elem_id, SND_CTL_ELEM_IFACE_MIXER);
  snd_ctl_elem_id_set_name(elem_id, DAC_VOLUME_NAME);
  snd_ctl_elem_id_set_index(elem_id, idx); // TER: Added
  long db_gain = 0;

And in mixer.c: mixer_volume_to_db()
 remove the clear() and set an index:

snd_ctl_elem_id_t *elem_id;
snd_ctl_elem_id_alloca(&elem_id);
//snd_ctl_elem_id_clear(elem_id); // TER: Removed
snd_ctl_elem_id_set_interface(elem_id, SND_CTL_ELEM_IFACE_MIXER);

/* IEC958_MULTI_CAPTURE_VOLUME, for stream=19 or 20 gives incorrect 
   results, use HW_MULTI_CAPTURE_VOLUME for all */
// Verified by TER. Those two controls have no dB values, but they should, 
//   they're just part of the same mixer !
//  snd_ctl_elem_id_set_name(elem_id, (stream <= 10) ? 
//   MULTI_PLAYBACK_VOLUME : (stream <= 18 ? HW_MULTI_CAPTURE_VOLUME : 
//   IEC958_MULTI_CAPTURE_VOLUME));
snd_ctl_elem_id_set_name(elem_id, (stream <= 10) ? MULTI_PLAYBACK_VOLUME :  
   HW_MULTI_CAPTURE_VOLUME); 

// TER: First line is 'proper' way, but second line is corrected 
//   workaround for lack of dB values for IEC958 controls.
//snd_ctl_elem_id_set_index(elem_id, stream <= 18 ? (stream - 1) % 10 : 
//   (stream - 1) % 18 );
snd_ctl_elem_id_set_index(elem_id, stream <= 18 ? (stream - 1) % 10 : 0 );

-
With the ice1712 digital mixer, it is not so crucial that we pay attention to 
 what ALSA tells us about those controls. 
Setting an index with snd_ctl_elem_id_set_index() is not crucial.
After all, this app is specifically for ice1712 and nothing else, so we know
 that it's always going to be an ice1712 chip, so we can take advantage
 of this, and 'hard-code' the digital mixer scale markings and other things.
The ADC/DAC section however, is a different matter.
Here is where we must pay attention to ALSA because we don't know
 what kind of codec chips may be used.
We can't even assume that all controls in a group have the same range so 
 to be safe we must use snd_ctl_elem_id_set_index().
Granted, envy24control does use some card-specific code for some tricks,
 but to support new cards with yet-unknown codecs, we must trust ALSA.
If we wanted utmost dB accuracy, we'd have to use card-specific code for 
 the AK4524 chip for example, due to the broken ALSA TLV functionality,
 as Clements mentioned in another thread.
These are the approaches I'm using in my re-work of the scales and page snaps.

And finally, a reminder (also to myself) to try to avoid using newer gtk
 functions because this app is 'supposed' to be able to built with gtk-1.
Those 'built-in' GtkScale marker functions are new since 2.16, and likely the 
 app could not be built with gtk-1.
I guess bumping up to a minimum of gtk+-2.0 might be OK though, 
 as it is the year 2010... Anyone still using gtk+-1.x ?

Tim.

On August 3, 2010 09:36:54 pm Niels Mayer wrote:
> FYI, I added the following since
> http://nielsmayer.com/envy24control/mudita24-1.0.1.tar.gz
> ... shall I release a 1.0.2 with the following additions (?):
>
>* fixed --card and --device to allow valid ALSA names and numbers
> ( https://bugzilla.redhat.com/show_bug.cgi?id=602900 ).
>   * Add display of "Delta IEC958 Input Status" under "Hardware Settings."
>   * Updated and corrected manual page and README
>
> Before I release, I'd like to know what happens on cards that don't
> have this feature, or if it's universally supported, but badly named.
> Can those with a Terratec or other card test the following command and
> let me know the results of command "amixer -c M66 cget
> iface=MIXER,name='Delta IEC958 Input Status'"
>
> e.g.:
> >> amixer -c M66 cget iface=MIXER,name='Delta IEC958 Input Status'
> >> numid=50,iface=MIXER,name='Delta IEC958 Input Status'
> >>  ; type=BOOLEAN,access=r---,values=1
> >>
> >>  : values=on
>
> ...
>..
>
> Also, in case anybody ever wondered what this one, under "Analog
> Volume" is for: "Volume Contr

Re: [LAD] [LAA] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 31, 2010 04:20:55 am James Morris wrote:
> On 31 July 2010 02:19, Niels Mayer  wrote:
> >> Yes, the CPU usage is from envy24control. Somehow, strange as it
> >> sounds... The higher the volume, the higher the CPU usage... Or, if
> >> the audio output is continually loud, it seems to overload the meters
> >> and CPU usages rockets.
> >
> > I've reproduced and fixed this problem. It had to do with a strange
> > "Gtk-oscillation" in UI sizing that would happen whenever label
> > "0dBFS" would get drawn into the digital mixer meter pair (which would
> > of course occur with louder signals :-) ). Lesser (or at least more
> > computationally tractable) oscillations within the pane of
> > sliders&meters might also happen, but the "earthquake" caused by the
> > digital mixer panel on the LHS resizing had an interesting "feedback
> > loop" that would take quite a while to "settle out" event-wise.
>
> Oh.. I had noticed a slight shaking but didn't think to mention it,
> thinking it was just a cosmetic fault.
>
The gui resizes a bit whenever a dB label changes the number of
 digits in the label. Maybe that's what was seen, rapidly?

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

Hey gang. Took a break for a few days...

On July 28, 2010 09:10:32 pm Tim E. Real wrote:
> Although slider thumb track size is known, extra unknown space 
>  above and below the slider trough may make our custom marker 
>  positions not precisely accurate.
Talk about whack-a-mole, gtk 2.20 has functions to determine those
 exact spaces. However I don't have 2.20 on my one-year-old distro.
So I feel they're too new to use always, but I can put some #ifdef 's
 in there to take advantage of them if available.

> However, if we're lucky, we may be able to keep page snaps by
>  intercepting keyboard page up/dn and forcing the sliders to their
>  very own page stops.
> I hope there's a way to intercept the KB.
> Some toolkits let you give the application or window first crack
>  at KB events before passing them on.
Yes, of course, that was easy.
In envy24control.c connect all of the vscale slider objects 
 to a single key handler:

  // Let us handle the page up/down snapping.
  gtk_signal_connect(GTK_OBJECT(vscale), "key-press-event", 
 GTK_SIGNAL_FUNC(slider_key_handler),
 0 );

The slider_key_handler() does all the rest of the work.
In the handler, gtk passes you the object which called it. Perfect.
Unlike QT, which sort of frowns upon that ("breaks modularity")
 and requires you to ask what the object was.
I've got my handler done. Works just fine. 
That is, I've got slider page up/down snaps, with no markers needed!

Just one problem:
For the ADC sliders, the top dB value is +18.5dB.
Therefore if we just 'blindly' move the slider 12 steps to the next
 6dB positions, we get +12.5, +6.5, +0.5 dB etc.
That '.5' offset, all the way up and down the scale, is not good.

So my next step is to use the ALSA dB functions (_ask_dB) 
 to 'ask' what the corresponding integer values are for
 +18.0, +12.0, +6.0, +0.0 etc. and these will then be the correct
 positions to set our page stops.

I'm pretty sure, if I can finish this, it will be all you (we) wanted 
 originally, and more.

Niels do you have a new release or repo I can work with rather than
 the original release, which may be too outdated to patch against by now?

Thanks. Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 28, 2010 08:12:39 pm Tim E. Real wrote:
> So I think the best solution now is let the application custom draw
>  the marks in a blank window beside the sliders.
> The key is to pay attention to the half-way point of the 
 > thumb track size, 
Although slider thumb track size is known, extra unknown space 
 above and below the slider trough may make our custom marker 
 positions not precisely accurate.

However, if we're lucky, we may be able to keep page snaps by 
 intercepting keyboard page up/dn and forcing the sliders to their 
 very own page stops. 

I hope there's a way to intercept the KB. 
Some toolkits let you give the application or window first crack
 at KB events before passing them on. 
Would be a big turnaround in this game. 

If finished, would be more or less identical to what Niels originally 
 wanted and we have now, but better, no?

Seems more plausible than attempting to intercept mouse
 movement with the current markers and trying to force the
 slider to not snap.
 
PS: If you look in gtk_range there are some internal 
 'slider inertia stops' functions, unfortunately they appear to affect 
 all the marks, too.

Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 27, 2010 09:09:51 pm Tim E. Real wrote:
> So if that's the case, then we could simply try my first idea, just throw
> up a vbox beside the slider with labels (and careful upper/lower item
> expansion). I'm trying this in Glade.
Follow-up: Close but no cigar.
There are oh-so-subtle problems with each label's top and bottom
 stretching. Even with extra 'gtk_alignment' widgets on top and bottom,
 I couldn't seem to perfect it.

So I think the best solution now is let the application custom draw 
 the marks in a blank window beside the sliders.

Bonus: We can fit as many markings as we want, and draw them
 any way we want to! It's just all pure graphics drawing now.

I think this is probably what one would have to do with most other 
 brands of slider widgets anyway.

The key is to pay attention to the half-way point of the 
 thumb track size, which is available, and carefully
 draw the top and bottom marks with that in mind, as well
 as the other marks. Thus allowing for different themes and styles.

I'll try to give it a go.

PS: About making the current markings optional:
If possible if you have time, try to make the option 'live'
 with a button so users can rapidly switch it on and off.
That would be most awesome. 
When you need it, click, and there it is.

Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 27, 2010 08:04:26 pm you wrote:
> On Tue, Jul 27, 2010 at 3:56 PM, Tim E. Real  wrote:
> > Sorry my mistake. Markers are required for page up/down snaps,
> >  as Niels said before.
> > Too bad. That feature was quite handy, eh?
> > And the marks looked sooo nice.
> > And we need at least mark for one unity gain.
>
> Tim -- thanks for  playing Gtk-whackamole with the markers and scale
> widgets. It became quite annoying. I began to wonder if I shouldn't be
> spending time getting "kenvy24" working instead. :-)

Stopped by a widget. I mean yeah it's not so bad, but, well...
Yeah, make it an option (really, it's very nice and useful!) 
 and I'll try to deal with it. I'll post patches to whatever you
 release, to ALSA or here. 
Thanks for helping out and listening to me.

KDE does not appear to have its own slider, at least in QT-Designer.
(Looked at KRuler widget, can't get it to turn vertical when I set its
 orientation in Designer.)

QT sliders don't seem to have that level of functionality of gtk's. 
That is, their thumb tracks simply move one page from where you *are*
 (just like gtk's does without, or in between, marks) even with ticks enabled.

Chalk one up for gtk there.

So if that's the case, then we could simply try my first idea, just throw up a 
 vbox beside the slider with labels (and careful upper/lower item expansion).
I'm trying this in Glade. 

Like Fons, I still hold out hope for something simple we're missing about
 this widget.
I never rewrote a gtk+ control before (plenty QT), but I may just try it.
Who knows maybe I'll have a patch for a new option, for the mouse snap.
'Cause, uh, um, I'm crazy I guess...
Er, it could, you know, ahem, ahem, cough, cough, work... Aahhh

Cheers. Tim

>
> I am incorporating your earlier suggestions into the code. Looking
> forward to what you come up with on the scale gain/attenuation values.
> I personally don't find the current behavior offensive, although the
> detenting should be optional... and actually prefer the keyboard
> up/down and page/up-down control better. Also the midi control
> shouldn't be bothered by the detents:
That doesn't sound too good either.

>   -m, --midichannel   midi channel number for controller control
>   -M, --midienhanced  Use an enhanced mapping from midi controller to 
> db
> slider (note the latter using a db lookup table that's in midi.c, i
> believe)
>
> Then you can use whatever slider implementation you prefer, but, alas
> , not for the things you might want to control.
>
> Also https://bugzilla.gnome.org/show_bug.cgi?id=565656 is the original
> patch for the scale widgetry.
> Matthias Clasen [reporter] [gtk+ developer] 2008-12-25 23:34:28 UTC
> ...
> Sometimes it is useful to point out certain values in a scale, and make it
> easy for the user to select them exactly. See e.g bug 565144
> ( https://bugzilla.gnome.org/show_bug.cgi?id=565144 ) where a scale is used
> for fade control between left and right, and midpoint would be very
> beneficial. Another use case would be to mark the 0dB position on a volume
> slider.
>
> Here is a patch that adds this feature to GtkScale. It allows to place
> "marks" on either side of the scale, optionally with text or icons.
> Behaviour-wise, selecting the mark values is made easier by adding a little
> resistance while dragging the slider with the mouse, and making keynav go
> exactly to the mark value instead of stepping over it.
> ..

>
> Actually, I'm not sure whether this is Gtk-whackamole, or groundhog day :-)
> If they'd just fill their divets there'd be no detents for the slider
> to get stuck on.
>
> Niels
> http://nielsmayer.com

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 27, 2010 04:08:11 pm Tim E. Real wrote:
> but we get to still keep the handy page up/down snaps,
> as they are part of gtk_adjustment etc.
Sorry my mistake. Markers are required for page up/down snaps,
 as Niels said before. 
Too bad. That feature was quite handy, eh? 
And the marks looked sooo nice. 
And we need at least mark for one unity gain.

Have Glade open, experimenting.  Later...

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 26, 2010 04:50:04 am f...@kokkinizita.net wrote:
> On Sun, Jul 25, 2010 at 04:55:10PM -0700, Niels Mayer wrote:
> > On Sun, Jul 25, 2010 at 3:23 PM,   wrote:
> > > - The analog gain sliders behave strangly. They seem to 'detent'
> > > on the scale marks, it's quite impossible to set a value *near*
> > > a scale mark while at the same time the resulotion halfway
> > > between scale marks seems to be OK.
> >
> > This is a side effect of routines I added to draw markings in the
> > scale widgets. GTK automatically auto-detents at the markings -- it's
> > certainly not what I wanted. (See volume.c: e.g.
> > draw_24bit_attenuator_scale_markings(), draw_dac_scale_markings() &
> > draw_dac_scale_markings()  called out of
> > envy24control.c:create_analog_volume()).
>
> I just don't believe that GTK can't create a slider without these
> detents (which don't work well either). It would be utterly broken.
> Try using such a fader for any real audio work.

Tested: Oh dear. I see what you guys mean now.
It's not hysteresis I was seeing, per se, but a desire for the
 slider to snap to the marker detents. 
Which is caused by adding the marks to the sliders in the first place.

Possible fixes:
1) Draw the markings as a completely separate entity
from the sliders. We don't necessarily need tick marks,
but we get to still keep the handy page up/down snaps,
as they are part of gtk_adjustment etc.
2) Sub-class gtk_scale, and by necessity gtk_vscale.
I could take a stab at it. But do we want this?

I think 1) is the best attempt for now. 
Let me take a look at how to draw them on their own.
They must expand when the the sliders expand, of course.
So maybe a bunch of labels inside an expanding vbox.

Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[Tim E. Real]

On July 27, 2010 01:00:31 am you wrote:
> On Mon, Jul 26, 2010 at 5:15 PM, Tim E. Real  wrote:
> > On July 16, 2010 10:10:48 pm Tim E. Real wrote:
> >> > Here we go!   snd_mixer_selem_get_playback_dB(  )
> >> >
> >> > Problem solved? Accurate or not?
> >
> > Not accurate with AK4524 chip. Read on...
>
> [...]
>
> > Yikes! It's all coming back to me now, this can of worms.
> > In my case the Delta101LT card has the AK4524 ADCs.
> > The dB step of the IPGA stage is constant at 0.5dB, but the
> >  dB step of the DATT stage is not - anywhere from 6dB to 0.28dB !
> > And remember the IPGA and DATT controls were combined, complicating
> > things. Meanwhile, other AK chips' DATT stages are constant step.
>
> So does this mean 'alsamixer' has a bug for those card models with
> combined IPGA? Which would that be?
>
> Note the code in 'alsamixer' which prints out dB-values -- is this
> correct or not?
Apparently there is a more advanced TLV based dB conversion.
snd_tlv_convert_to_dB()

If it is true, then in that respect, could we say this code should 
 be updated to use the TLV dB functions, for better accuracy?
Because at constant 0.5dB steps, the dB labels in alsamixer and 
 envy24control sure don't seem to correspond closely to what's 
 in the AK4524 datasheet dB table.
I do hope I'm reading that datasheet right !

Now, a question is: If TLV proves more accurate, do we really want 
 these odd value yet more accurate markings. Like -18.32 not -18.

Ie maybe pseudo 0.5 dB steps are better, visually.
I'm starting to think so. 
It's a compromise after all. Not terribly accurate but it works.
It would become a problem if large inaccuracies arise with some chip.
Ah, maybe a user switch - regular constant, or TLV based for accuracy.

But I need to study that TLV stuff more...
See my other post about successful experiments with other dB funcs.

>
> alsa-utils-1.0.23/alsamixer/mixer_display.c :
>   ... if (control->flags & (TYPE_PVOLUME | TYPE_CVOLUME)) {
>   int (*get_vol_func)(snd_mixer_elem_t *, 
> snd_mixer_selem_channel_id_t,
> long *);
>
>   if (control->flags & TYPE_PVOLUME)
>   get_vol_func = snd_mixer_selem_get_playback_dB;
>   else
>   get_vol_func = snd_mixer_selem_get_capture_dB;
>   if (!(control->flags & HAS_VOLUME_1)) {
>   err = get_vol_func(control->elem, 
> control->volume_channels[0], &db);
>   if (err >= 0) {
>   dbs = format_gain(db);
>   value_info = casprintf(" [%s %s]", _("dB 
> gain:"), dbs);
>   free(dbs);
>   }
>   } else {
>   err = get_vol_func(control->elem, 
> control->volume_channels[0], &db);
>   if (err >= 0)
>   err = get_vol_func(control->elem, 
> control->volume_channels[1], &db2);
>   if (err >= 0) {
>   dbs = format_gain(db);
>   dbs2 = format_gain(db2);
>   value_info = casprintf(_(" [%s %s, %s]"), _("dB 
> gain:"), dbs, dbs2);
>   free(dbs);
>   free(dbs2);
>   }
>   }
>   }
>
> > 
> > Hey look what I found: A bunch of other dB related funcs like:
> >
> > snd_mixer_selem_get_playback_dB_range (snd_mixer_elem_t *elem,
> >  long *min, long *max)
> > "Get range in dB for playback volume of a mixer simple element. "
> >
> > Now, this would certainly help with markings - if the dB step were
> > constant. We would know by the number of integer steps where the 0dB
> > point was etc.
> >
> > But even better, look at this one! :
> >
> > snd_mixer_selem_ask_playback_vol_dB (snd_mixer_elem_t *elem, long value,
> >  long *dBvalue)
> > "Return corresponding dB value to an integer playback volume for a
> >  mixer simple element. "
> >
> > The thing is, for the AK4524, ALSA reports only a single constant
> >  step of 0.5, and says the minimum is -63.5dB, with 163 integer steps
> >  and a max of +18.5dB.
> > It does kinda sorta all work out, but in a average step sort of way...
> > ALSA would need to use a dB table (exists?) to be accurate here.
> >
> > So, we're basing our scales on somewhat dubious info.
> > But no dou

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 26, 2010 09:07:35 pm you wrote:
> On Mon, Jul 26, 2010 at 12:29 AM, Tim E. Real  wrote:
> >  trust me it will look great at the expense of only 28 extra pixels for
> >  the minimum height over the original - it's all you can really do, man:
> >
> > Remove the -72 and -108 dB marks on all the monitor sliders
> >  in volume.c: draw_24bit_attenuator_scale_markings().
> >
> > Remove the -42 and -54 dB marks from the DAC sliders in
> >  volume.c: draw_dac_scale_markings().
> >
> > Remove the -18, -30, -42, -54, -60 dB markings from the ADC
> >  sliders in volume.c:draw_adc_scale_markings().
> >
> > Change the level meter heights by changing
> >  gtk_widget_set_usize(drawing, 24, (60 * tall_equal_mixer_ht + 204));
> >  to
> >  gtk_widget_set_usize(drawing, 24, (60 * tall_equal_mixer_ht + 168));
> >
> >  in envy24control.c: create_mixer_frame().
> >
> > Trust me they'll love it !
>
> Thanks! Yes, it does look better. I've applied these suggestions to my
> current sources and they'll be part of an upcoming release that
> addresses the issues...
>
> If you have any suggestions on getting rid of the annoying
> detent/hysteresis as you move the sliders past the markings, that
> would be great.
>
> -- Niels.
> http://nielsmayer.com

Sure, NP I'll take a look.

Good news! 
As I mentioned in a follow-up to another thread, I found a bunch 
 more dB related functions.

I tested replacing the code in volume.c:dac_volume_to_db() and
 adc_volume_to_db() with a call to ALSA's snd_ctl_convert_to_dB().

The results are identical! And better for ADC compatibility, right?

Now comes the fun part. Coming up with an Al-Gore-rithm to
 handle the scale markings using these ALSA functions - 
 how many 6dB steps we have, which ones to display, the range, etc.

It occurred to me 'dynamic markings': If the user expands 
 more, or less, vertically, then more, or less, markings should appear.
But it's still tricky - we want it to look the way I suggested above,
 with more markings concentrated around the 0dB point, whenever
 we are forced to compromise by removing marks.
Ultimately, at minimum height it must look like that - it's a compromise,
 until a (better) solution comes up.

Also I see there is something called TLV based dB conversion where 
 I think it's a table or can be an arbitrary function. Must study more.


For now here's the code, throw it inside 
 dac_volume_to_db() and 
 adc_volume_to_db() but *replace* DAC_VOLUME_NAME with ADC_VOLUME_NAME,
 and I believe mixer_volume_to_db() and wherever else required. 
Do you need a patch?

Hope this is OK, not sure how many members to set in struct snd_ctl_elem_id.
List members, does it look OK?

char* dac_volume_to_db(int ival) {
 if (ival != 0) {
 
  // Use ALSA functions to get dB values.
  long db_gain = 0;   
  float fval;
  snd_ctl_elem_id_t *elem_id; 
  snd_ctl_elem_id_alloca(&elem_id); 
  snd_ctl_elem_id_clear(elem_id);
  snd_ctl_elem_id_set_interface(elem_id, SND_CTL_ELEM_IFACE_MIXER);
  snd_ctl_elem_id_set_name(elem_id, DAC_VOLUME_NAME);
  snd_ctl_convert_to_dB(ctl, elem_id, ival, &db_gain); 
  fval = ((float)db_gain / 100.0);
  sprintf(temp_label, "%+2.1f", fval);
  return (temp_label) ;

 }
 else
 {
// Rest of function ('off' part). ]
   ...

Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

[Tim E. Real]

On July 16, 2010 10:10:48 pm Tim E. Real wrote:
> > Here we go!   snd_mixer_selem_get_playback_dB(  )
> >
> > Problem solved? Accurate or not?
Not accurate with AK4524 chip. Read on...

>
> Slider markings still not possible with this - it is only a 'current'
> value.
>
> But that's OK, I'm now thinking markings on every slider would be clutter.
> Instead, let's have a dB label below the integer value label, and use
>  snd_mixer_selem_get_playback_dB() to fill it.
>
> I think that might be reasonable. dB markings may be impossible here...
>

{snip}
> I don't remember why I didn't try to take care of it,
> if there was some difficulty in the actual dB numbers or
> something, or probably just never got around to it.

{Much discussion elsewhere...}

Yikes! It's all coming back to me now, this can of worms.
In my case the Delta101LT card has the AK4524 ADCs.
The dB step of the IPGA stage is constant at 0.5dB, but the 
 dB step of the DATT stage is not - anywhere from 6dB to 0.28dB !
And remember the IPGA and DATT controls were combined, complicating things.
Meanwhile, other AK chips' DATT stages are constant step.


Hey look what I found: A bunch of other dB related funcs like:

snd_mixer_selem_get_playback_dB_range (snd_mixer_elem_t *elem, 
 long *min, long *max)
"Get range in dB for playback volume of a mixer simple element. "

Now, this would certainly help with markings - if the dB step were constant.
We would know by the number of integer steps where the 0dB point was etc.

But even better, look at this one! : 

snd_mixer_selem_ask_playback_vol_dB (snd_mixer_elem_t *elem, long value, 
 long *dBvalue)
"Return corresponding dB value to an integer playback volume for a 
 mixer simple element. "

The thing is, for the AK4524, ALSA reports only a single constant 
 step of 0.5, and says the minimum is -63.5dB, with 163 integer steps
 and a max of +18.5dB. 
It does kinda sorta all work out, but in a average step sort of way...
ALSA would need to use a dB table (exists?) to be accurate here. 

So, we're basing our scales on somewhat dubious info.
But no doubt these dB functions should be very helpful in drawing
 scales for all ADC chips on ice1712 cards, no?

The "impossible" is possible?

Hope this helps. Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 26, 2010 03:35:43 pm you wrote:
> I'd have a better advantage if I had the motivation to add tooltips or
> a language catalog, which sounds very tedious to try and do by myself.
> Of course, if someone else wants to work on it, I'd be happy to
> investigate and integrate any patches coming my way. Right now I'd
> want to focus on correcting existing problems and submitting that as a
> patch to ALSA.
>
Yeah, don't worry too much about it. After all, it was my own fault
 about that lock control for not 'knowing my card', and I overreacted a bit.
Plus, anyone with one of these cards is likely to have bought it themselves 
 and/or have a manual, as I do. So tooltips may be nice but unnecessary here. 
And tooltips would not have clued me into why I had no Flash audio, he he...

>
> PS: Just learned of another ICE1712-based interface -- that isn't
> recognized by Linux and that comes up with ADC/DAC's totally
> unrecognized by snd-ice1712 -- and that fortunately causes the entire
> "Analog Volume" panel to not show (as opposed to crashing), but
> otherwise the new envy24control does allow mixer control of it...
> http://www.soundonsound.com/sos/aug02/articles/edirolda2496.asp (looks
> nice the Roland/Edirol DA2496). Meanwhile, pictures show Fons using
> the http://www.soundonsound.com/sos/oct99/articles/terratec.htm .
> Keeping same A/D-D/A section, the follow-on offering
> http://www.soundonsound.com/sos/apr04/articles/terratecphase88.htm
>   leading me to conclude that of all the ice1712 interfaces,
> the Delta 1010 has the best converters, using AK5383 versus AK4524
> (Delta 44/66/1010lt & all terratec's from dmx6fire to phase88).
I'm following these other posts. Interesting variations. Nice to know my card
 is good.

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 26, 2010 03:29:13 am Tim E. Real wrote:
> I just noticed that the upper red part of all the meters are gone.
> Any plans to re-instate that red coloured portion?
> I fear a backlash on that.
Sorry was not paying full attention, I see the top is actually 0dBFS.
Hmm, I think I see your point there.

So having coloured portion makes no sense?
But could it not be useful as a warning area?

Tim.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 25, 2010 08:00:23 pm you wrote:
> On Sun, Jul 25, 2010 at 3:57 PM, Tim E. Real  wrote:
> > CPU 20% on idle, and when adjusting sliders it's around 50%. All OK.
> Is this more CPU load or less than the original envy24control? It
> should be a lot less load.
Oops, don't know where that 20% came from. Something must have been running.
Both mixers consume nothing until woken up, and then as a silly test I 
 operated the sliders, original consumes ~30% new one ~50%, but of course
 that's probably just because they do a bit more work now when operated.
When I provide some input and watch the meters, still no CPU consumption.
Is there some test you want me to do?
It's a 32 bit system, btw.

> If anybody has suggestions on shrinking the sliders in "Analog
> Volumes" I'm all ears. I was a but stumped at their resistance to
> changing height, and gave up.
Did some coding... Yep, gtk_scale sure is rather unforgiving
 in its spread. It is the number of marks causing this.
We ask it for fifteen ADC slider markings, and it does this ?
I even tried xx-small font size (which still looks good), but no change.
And I tried removing the texts, leaving just the ticks. No change.

Niels, please do the following (sorry I don't have a patch for you),
 trust me it will look great at the expense of only 28 extra pixels for 
 the minimum height over the original - it's all you can really do, man:

Remove the -72 and -108 dB marks on all the monitor sliders
 in volume.c: draw_24bit_attenuator_scale_markings().

Remove the -42 and -54 dB marks from the DAC sliders in
 volume.c: draw_dac_scale_markings().

Remove the -18, -30, -42, -54, -60 dB markings from the ADC 
 sliders in volume.c:draw_adc_scale_markings().

Change the level meter heights by changing
 gtk_widget_set_usize(drawing, 24, (60 * tall_equal_mixer_ht + 204));
 to
 gtk_widget_set_usize(drawing, 24, (60 * tall_equal_mixer_ht + 168));

 in envy24control.c: create_mixer_frame().

Trust me they'll love it !

I just noticed that the upper red part of all the meters are gone.
Any plans to re-instate that red coloured portion?
I fear a backlash on that.

IIRC I observed behaviour you described about the last slider marks 
 requiring no text. Seemed that if you give the last mark text,
 it goes ahead and puts a blank one at the end? Not sure.

>
> > I too noticed odd monitor and volume slider behaviour, not present
> >  in the original mixer.
> > The slider knobs have a large amount of 'hysteresis', that is they
> >  don't move until you move the mouse a large amount.
I did not take a look at the slider 'hysteresis' problem though, sorry.

Have great day and a better tomorrow. 
Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 25, 2010 06:57:42 pm Tim E. Real wrote:
> I propose that the "multi track rate locking" be renamed to just
>  "lock" ( *not* "locked" because believe it or not I actually thought
>  that was an indicator, not a control - there is confusion with the
>  "locked" label underneath the "word clock" button, speaking of which
>  should be moved down slightly or coloured because it reads like
>  "word clock locked" ), and that "multi track rate reset" be renamed to
>  "reset", and that the "Rate State" group box be renamed to
>  "Multi Track Rate State" *or* left alone at just "Rate State" because
>  frankly I find the phrase "Multi Track" a bit confusing esp. in other
> mixers, but you are right, it should match what ALSA calls it.
Er, sorry scratch that. Again, you are right, they should match what 
 ALSA calls them. And "... locking" is still better than "locked".

So I say instead some descriptive tooltips would be very handy
 for users, at least on the hardware settings tab, even if there
 is a manual. But what about language translations? Is that 
 more or less automatic, or requires intervention?

You'd have a good advantage over other mixers there with real
 descriptions. Tim.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] announcing envy24control, mudita (*) edition.

[Tim E. Real]

On July 25, 2010 03:10:44 pm Niels Mayer wrote:
> Summary of updates from envy24control 0.6.0 (GIT HEAD) to "1.0.0":
>
> (0) After a decade, incremented version to 1.0.0 (**)
> (1) Implemented missing "Peak Hold" functionality in meters and
> reimplemented meters for increased efficiency and lower X resource
> usage. (see http://www.linuxaudio.org/mailarchive/lad/2010/7/12/171535
> & https://bugzilla.redhat.com/show_bug.cgi?id=602903 )
> (2) All volumes are represented as decibels, including the 0 to -48dB
> range of the hardware peak-meters, the 0 -to- -144dB attenuation for
> all inputs to the digital mixer, the 0 -to- -63dB attenuation of the
> analog DAC, and the +18 -to- -63dB attenuation/amplification of the
> analog ADC.
> (3) All gtk "scale" widgets have dB legends; the "PageUp" "PageDown"
> keys allow rapid movement between the marked levels.
> (4) Got rid of myriad compile warnings and other minor fixes across
> codebase.
>
> Some screenshots:
> http://nielsmayer.com/envy24control/Screenshot-Envy24Control-AnalogVolume.p
>ng
> http://nielsmayer.com/envy24control/Screenshot-Envy24Control-MonitorInputs.
>png
> http://nielsmayer.com/envy24control/Screenshot-Envy24Control-MonitorPCM.png
>
> 
>
> To the ALSA project: please consider this patch to alsa-tools'
> envy24control (**):
> http://nielsmayer.com/envy24control/envy24control-0.6-to-1.0.patch
> (patch to 'envy24control' from GIT trunk/head of alsa-tools)
> http://nielsmayer.com/envy24control/envy24control-1.0.README
> (summary of changes from 0.6.0 to 1.0.0)
>
> 
>
> Those wanting to compile directly, or run a 64 bit linux binary I've built:
>
> http://nielsmayer.com/envy24control/envy24control-1.0.tar.gz
> (full directory, just follow README directions to build/install)
> http://nielsmayer.com/envy24control/envy24control-1.0-fc12-x86_64.tar.gz
> (x86_64 binary that should work on fedora12 and equivalent OpenSuse
> release)
>
> I'd appreciate any testing results or comments on this "1.0.0"
> release. In particular, I'd like some assurance that the dB markings
> on sliders in "Analog Volume" panel are correct (compared to values
> reported by 'alsamixer'). I'm looking for testing with following
> devices (as I think my testing covers code for M-Audio Delta 44 &
> Delta 66, Terratec Dmx6fire & EWX2496) specifically:
>   M-Audio Delta 1010, M-Audio Audiophile 2496, M-Audio Delta 1010LT
>   TerraTec EWS 88MT, TerraTec EWS 88D, TerraTec Phase 88,
>   Hoontech SoundTrack DSP 24 (all variants).
>
> Thanks,
>
> Niels
> http://nielsmayer.com
>
> PS:
> (*) http://en.wikipedia.org/wiki/Envy#In_philosophy :: "mudita, taking
> joy in the good fortune of another. This virtue is considered the
> antidote to envy and the opposite of schadenfreude."
>
> (**)
> http://git.alsa-project.org/?p=alsa-tools.git;a=tree;f=envy24control;h=d5a5
>6728048135649314456191fe8559c4f68118;hb=HEAD

Single device here: MAudio Delta1010LT card:

CPU 20% on idle, and when adjusting sliders it's around 50%. All OK.

You asked for it, he he...

Can't resize height below certain amount - it's too tall.
I don't see what tab or control is preventing it. 
Maybe the analog volume controls... 
Ah - maybe their slider scale markings and numbers. 
Too many of them vertically?

I too noticed odd monitor and volume slider behaviour, not present
 in the original mixer.
The slider knobs have a large amount of 'hysteresis', that is they
 don't move until you move the mouse a large amount.

I propose that the "multi track rate locking" be renamed to just 
 "lock" ( *not* "locked" because believe it or not I actually thought 
 that was an indicator, not a control - there is confusion with the 
 "locked" label underneath the "word clock" button, speaking of which 
 should be moved down slightly or coloured because it reads like 
 "word clock locked" ), and that "multi track rate reset" be renamed to
 "reset", and that the "Rate State" group box be renamed to
 "Multi Track Rate State" *or* left alone at just "Rate State" because
 frankly I find the phrase "Multi Track" a bit confusing esp. in other mixers,
 but you are right, it should match what ALSA calls it.
Whew.

Well, cheers, talk @ you later. Tim.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Solved: No Flash audio. With a question.

[Tim E. Real]

On July 25, 2010 10:40:22 am you wrote:
> On Sat, Jul 24, 2010 at 8:41 PM, Tim E. Real  wrote:
> > I turned off the 'lock' control in envy24control and now Flash can
> >  set the rate to 48000Hz.
>
> I forgot to mention the "Multi Track Rate Locking" and "Multi Track
> Rate Reset" issues...  Or the fact that sometimes you have to switch
> the clock rate around a few times manually to force it to reset when
> externally sync'd via SPDIF...
>
> Part of the problem is that the "Locked" and "Reset" are badly named
> in envy24control.
> In a screenshot I didn't include, one of the minor changes I made is
> to use the  standard ALSA names,
> so at least the poor user faced with weird lockups can get some
> meaningful google searches back:
> http://www.google.com/search?hl=en&q=ice1712+ice1724+multi+track+rate+locki
>ng or
> http://www.google.com/search?hl=en&q=ice1712+ice1724+multi+track+rate+reset
Yeah, if someone like me who's studied the code, can forget 
 (or never learned?) what that lock was for, imagine the 
 trouble others have. To be fair, I never RTFM, hmm, is there a manual?
I would prefer tooltips on some of those controls, although maybe that's
 not the right place to say "Leave lock off for normal usage" or something...
Trouble is, I think it boots up like that, with the lock on.

My friend who's setting up a studio and who's never tried linux before,
 has a Delta1010LT card (like me), and took the plunge and installed Ubuntu.

His first phone call to me was "Uh, Tim, no audio !"
Good thing he's got me to help, er, or hinder ...

Thanks for the amazing work on this. Will test and report.

Tim.

>
> ...
> @@ -667,7 +700,7 @@ static void create_rate_state(GtkWidget *box)
>   gtk_container_add(GTK_CONTAINER(frame), hbox);
>   gtk_container_set_border_width(GTK_CONTAINER(hbox), 6);
>
> - check = gtk_check_button_new_with_label("Locked");
> + check = gtk_check_button_new_with_label("Multi Track\nRate Locking");
>   hw_rate_locking_check = check;
>   gtk_widget_show(check);
>   gtk_box_pack_start(GTK_BOX(hbox), check, FALSE, FALSE, 0);
> @@ -676,7 +709,7 @@ static void create_rate_state(GtkWidget *box)
> (gpointer)"locked");
>
>
> - check = gtk_check_button_new_with_label("Reset");
> + check = gtk_check_button_new_with_label("Multi Track\nRate Reset");
>   hw_rate_reset_check = check;
>   gtk_widget_show(check);
>   gtk_box_pack_start(GTK_BOX(hbox), check, FALSE, FALSE, 0);
> ..
>
> Niels
> http://nielsmayer.com
>
> PS: Now playing, and generally excellent once you get past the talking
> (and amarok's or m4a's refusal to let me fast-forward past it...) It
> just suckers you in with that big fat "supersaw" (?) synth line at the
> beginning of "Subway to Cologne" I swear. (( requesting equivalent
> yoshimi patch, plz! ))
>
> http://www.whatpeopleplay.com/tracks/podcasts/27.m4a
>
> That's STORY #27
> DJ Mix by ??? including interview with the mysterious A&R of the
> secret STORY label
> Tracklisting:
> 1. story01-Subway To Cologne
> 2. story02 - deepcut59
> 3. story03-whobadu
> 4. Juju & Jordash - Hired guns - downbeat
> 5. Kai Alce - ??? - real soon
> 6. San Soda - Ode aan de Nacht  - we play house
> 7. stl - vintage hunter - something
> 8. Theo Parrish - I cant take it - sound signature
> 9. the mole - The Date - spectral
> 10. Trickski - ??? - still love 4 music
> 11. Dreevsn - ??? - acido
> 12. even tuell - lunch time with lowtec - out to lunch
> 13. Levon Vincent - Six figures - novel sound
> 14. Marcellus Pittman - Skylark - fxhe
> 15. Oni Ayhun - ooar003-b - oar

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev