I haven't used PulseAudio yet - but I imagine if the input data needs
to be copied, we'll suffer with regards to latency? I find dealing
with latency to be my number 1 most annoying problem when recording. I
guess we can cross that bridge when we come to it, but it's worth
thinking about, particularly when there are so many other issues to
iron out. To combat any latency issues effectively, the problems with
waveforms synching to the audio absolutely need to be fixed - there's
only so much anti-latency audio offsetting can be done automatically,
and since we can't predict what the user is actually trying to do, he
/ she has to be confident that the waveform is an accurate
representation of what is going to be played, so the user can just
drag the even to whatever position they want it.

Anyway, that's all irrelevant for now :P If I have time tonight I'll
take a look and maybe have a prototype patch ready - I imagine I can
just modify the patch Knut provided last year.


On 6/25/08, Laszlo Pandy <[EMAIL PROTECTED]> wrote:
> Your proposal is really good Tom. I think we're on the right track with
> this and we should be able to hammer out the details.
> As for the VUMeter which monitors the microphone volume, this is
> different than the VUMeter in the mixer view right now. The one we have
> implemented right now shows the *output* volume, and therefore is only
> active when the audio is playing.
> I am fairly certain that with standard alsa you cannot monitor the
> volume of the microphone without recording it, so having a VUMeter
> monitoring the input would block any other programs from using the
> microphone.
> PulseAudio solves this problem by automatically copying the microphone
> data to any program that requests it. But to enable this we would have
> to support querying the available input devices from pulseaudio, and
> using pulsesrc (a feature we were planning to support anyway).
> For now you can assume that this will work as long as you are using the
> default device. People with multiple inputs should have a more
> complicated setup anyway. If you want to try this out at home you can
> run two instances of the command:
> gst-launch-0.10 alsasrc device=default ! fakesink
> Two can run at the same time on my computer, but if I change device to
> hw:0, it complains that another application is using the device.
> Laszlo
> Tom Halligan wrote:
>> Hi Knut,
>> I agree completely with the volume control as a necessity,
>> particularly if Jokosher is to be considered the user-friendly audio
>> editor of choice. Right now I'm kind of leaning towards an
>> 'all-in-one' solution:
>> 1: Recording monitor when the instrument is armed for recording -
>> preferably with an input volume control if possible.
>> 2: Volume control when instrument is not armed for recording - this
>> could also be a peak monitor: even if the track is recorded without
>> peaking, further manipulation may cause peaks.
>> 3: When not armed for recording, it would make sense for the volume
>> control to incorporate the mute function - say, by right-clicking.
>> If we included all 3 points, we could get rid of the mute button
>> itself, and use the freed-up space to have a slightly larger vumeter
>> on the right hand side of the instrument viewer, which I think would
>> be the best solution.
>> On 6/25/08, Knut Erik Teigen <[EMAIL PROTECTED]> wrote:
>>> Hey,
>>> I was the one submitting that patch. I haven't really participated
>>> afterward, work on my
>>> PhD thesis has consumed all my time, unfortunately. But I try to follow
>>> the
>>> progress, and
>>> hope to contribute more when the dust settles.
>>> I really like the idea of having a VUWidget in the instrument view as
>>> well.
>>> Also, I believe pop-up buttons generally are a bad solution. Changing the
>>> volume is something
>>> you do very often when recording, so it should be instantly accessible.
>>> Regards,
>>> Knut Erik Teigen
>>> On Wed, Jun 25, 2008 at 3:42 PM, Tom Halligan <[EMAIL PROTECTED]>
>>> wrote:
>>>> I do like the mockup - maybe a little polish would be needed, but it
>>>> does the job. I don't really like the way it looks as if it's just
>>>> drawn on top of the InstrumentViewer, rather than an actual feature of
>>>> it, but that's just nit-picking.
>>>> I found this:
>>>> http://www.mail-archive.com/jokosher-devel-list@gnome.org/msg00239.html
>>>> Did you ever get a response? I'm not that up to date on gstreamer
>>>> itself so I'm not entirely sure what I'm looking for there - but since
>>>> Jokosher has a VUWidget anyway, am I right in assuming that the
>>>> problem is fixed? If so, we could just go ahead and try that patch,
>>>> maybe with a few alterations here and there (say, to include input
>>>> volume control, and track volume control when not armed to record?) -
>>>> see if people like it or not.
>>>> On 6/25/08, Laszlo Pandy <[EMAIL PROTECTED]> wrote:
>>>>> Tom Halligan wrote:
>>>>>> ....
>>>>>> Maybe the easiest solution would be to use a small, horizontal
>>>>>> VUWidget
>>>>>> rather than the current volume slider? Although this doesn't solve the
>>>>>> space issue - it would at least be more intuitive as a volume control,
>>>>>> and also doubles up as a level monitor. The mute functionality could
>>>>>> be
>>>>>> incorporated into this, so then we'd just have three buttons to deal
>>>> with.
>>>>> See this bug from a *really long* time ago:
>>>>> https://bugs.launchpad.net/jokosher/+bug/70351
>>>>> And the screenshot accompanying it:
>>>>> http://www.kryogenix.org/random/jokosher-vumeter.gif
>>>>>> Another option, although a lot more work than the above, would be to
>>>>>> implement a rotating 'dial' widget (like those used in FruityLoops,
>>>>>> for
>>>>>> example). This would look out of place with Jokosher, though - and I
>>>>>> don't think many people honestly like these things anyway, so probably
>>>>>> best to avoid it.
>>>>> This is explicitly prohibited by the Jokosher way, as originally
>>>>> defined
>>>>> by Jono when he wrote about the stupidity and unusability of audio
>>>>> editors which try to be familiar by copying the mixer desk controls.
>>>>> They fail miserably because mixing desks were not meant for mouse
>>>>> manipulation.
>>>>> The prime example of this is the rotating dial because it is really
>>>>> easy
>>>>>   to control with your fingers when you have grasp and tactile
>>>>> feedback,
>>>>> but it is absolutely impossible to use when a mouse pointer.
>>>>>> I do think a sliding control is still the best option, but I guess to
>>>>>> some, the horizontal slider would remind them of a pan control.
>>>>>> However,
>>>>>> the slider's 'groove' (Or whatever you want to call it) does become
>>>>>> shaded to the left of the slider handle, which does suggest some kind
>>>>>> of
>>>>>> 'increase' as we move towards the right, rather than just a left vs
>>>>>> right balance. Perhaps if we could make it more obvious that it was a
>>>>>> volume control somehow - although I don't think the confusion between
>>>>>> volume and pan would be anything serious, even for people used to such
>>>>>> a
>>>>>> thing. A fixed, vertical slider could be the easiest way around the
>>>>>> space issue, although this obviously means something else would have
>>>>>> to
>>>>>> be compromised.
>>>>>> Tom
>>>>>>     From: "Jeff Ratliff" <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
>>>>>>     To: jokosher-devel-list@gnome.org
>>>>>> <mailto:jokosher-devel-list@gnome.org>
>>>>>>     Date: Tue, 24 Jun 2008 08:33:07 -0400
>>>>>>     Subject: Re: [jokosher-devel] [PATCH] InstrumentViewer volume
>>>>>> slider
>>>>>>     patch (SVN Rev. 1519)
>>>>>>     Sorry, don't think I sent this to the list:
>>>>>>     The volume slider in this position makes the think of a pan
>>>>>> control,
>>>>>>     not a volume control. This comes from my experience with physical
>>>>>>     sound boards though, and a novice may not have this problem.
>>>>>>     You could do a volume icon that pops up a volume slider, a la
>>>>>>     rhythmbox and others. If you were really clever, you could find a
>>>> way
>>>>>>     to integrate it with the mute button and take up no additional
>>>> space.
>>>>>>     This is less discoverable though, and would really rely on a good
>>>>>>     descriptive icon, or a little mini popup arrow thingy (excuse my
>>>>>>     advanced technical jargon). :)
>>>>>> ------------------------------------------------------------------------
>>>>>> _______________________________________________
>>>>>> jokosher-devel-list mailing list
>>>>>> jokosher-devel-list@gnome.org
>>>>>> http://mail.gnome.org/mailman/listinfo/jokosher-devel-list
>>>> _______________________________________________
>>>> jokosher-devel-list mailing list
>>>> jokosher-devel-list@gnome.org
>>>> http://mail.gnome.org/mailman/listinfo/jokosher-devel-list
jokosher-devel-list mailing list

Reply via email to