GNU/Linux Audio Mechanics

On Mon, 28 Jan 2002, [iso-8859-1] J=F6rn Nettingsmeier wrote:

> hello * !
>
> i've just pulled glame v0.6.1, and it compiles and runs like a
> breeze. thanks heaps.
> (btw, maggy, the problems i reported when using alsa-i/o with an sb
> live are gone, and from the console output i'd say everything is as
> smooth as can be. i'm a happy glame user now :-] )
>
> one question: i've been playing with josh's vocoder port again, and
> i found that consonants were not too intelligible.
> so i thought i'd add a white noise source to the carrier. i used the
> glame one, but somehow it only outputs half a second or so of white
> noise, then falls silent.
> what am i missing here ?

You need to repeat the noise output - all wave generating plugins
just spit out a small fragment of their wave.

> and what does the "position" slider do ?

Its the position in the stereo field (-PI to PI, -PI/2 is left, PI/2 is
right, 0 is front (mono)).

Richard.

--
Richard Guenther <richard.guenther@...>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

On Mon, 2002-01-28 at 12:45, J=F6rn Nettingsmeier wrote:
> i've just pulled glame v0.6.1, and it compiles and runs like a
> breeze. thanks heaps.
> (btw, maggy, the problems i reported when using alsa-i/o with an sb
> live are gone, and from the console output i'd say everything is as
> smooth as can be. i'm a happy glame user now :-] )

Yeah, I hope so, I extra bought an SB Live. That's user service isn't it
;) I wanted to get one anyway.
=20
> glame one, but somehow it only outputs half a second or so of white
> noise, then falls silent.
> what am i missing here ?

You have to put the repeat filter behind it and enter a duration for
that it should output noise, or you could use the ladspa white noise
plugin.

> and what does the "position" slider do ?

With the position slider you can define the position of a track in a 2D
soundfield. Imagine a circle with angles defined from -PI/2(-90 degrees)
to PI/2(90 degrees). -PI/2 pins the track to the left and +PI/2 to the
right.

> ps: is too much to ask to be cc:ed on replies ? i follow about 10
> lists, and i begin to get reluctant subscribing to any more....

Glame users is pretty much dead, so you wouldn't have to fear any
traffic, but I can CC that's no problem.

Cheers, Maggy

[mag, i'm cc:ing glame-user, that's why i write in english]
Alexander Ehlert wrote:
> 
> On Mon, 2002-01-28 at 12:45, Jörn Nettingsmeier wrote:
> > i've just pulled glame v0.6.1, and it compiles and runs like a
> > breeze. thanks heaps.
> > (btw, maggy, the problems i reported when using alsa-i/o with an sb
> > live are gone, and from the console output i'd say everything is as
> > smooth as can be. i'm a happy glame user now :-] )
> 
> Yeah, I hope so, I extra bought an SB Live. That's user service isn't it
> ;) 

wow. did i mention that glame does not work well with my 40 channel
neve ? :-D
order here: http://www.ams-neve.com/

> > glame one, but somehow it only outputs half a second or so of white
> > noise, then falls silent.
> > what am i missing here ?
> 
> You have to put the repeat filter behind it and enter a duration for
> that it should output noise, or you could use the ladspa white noise
> plugin.

i see. is there a reason for this behaviour ?
normally i'd want an oscillator or noise source to go on endlessly.
would it be complicated to make this the behaviour for duration == 0
?

but it'll work for me as it is.
 
> > and what does the "position" slider do ?
> 
> With the position slider you can define the position of a track in a 2D
> soundfield. Imagine a circle with angles defined from -PI/2(-90 degrees)
> to PI/2(90 degrees). -PI/2 pins the track to the left and +PI/2 to the
> right.

yes.. i remember i laughed my head off on linuxtag when i realized
you were using rads as a panning unit :)
just forgot. anyway, how about "panorama" or "left<->right" as a
slider label ?

one more thing:

right now i'm using a spare sound card as an outboard effect for my
mixing desk. i build a filternetwork with gverb, choose hw1:0 as
alsa input and output device, and everthing works fine.

however, the latency is a bit high for my taste.
i measured 46 milliseconds, which is a bit much except maybe for
ballad reverbs. i wonder, is that a hardware constraint of my crappy
card (ens1371) or can i reduce the buffer size that glame uses ?
maybe you can give me a hint where to look in the sources ?

i tried the global settings dialog, but it has no effect, and it
does not allow for card-specific settings anyway. the proper place
for this is probably the "alsa-input->properties" widget...

btw, i've done about 2 cds worth of editing now with the new glame,
and i must say it has not crashed a single time for me yet. one can
kill it doing nasty things to the filternetwork, but other than
that, it's been rock solid for me. great work !

best,

jörn


-- 
Jörn Nettingsmeier     
home://Kurfürstenstr.49.45138.Essen.Germany      
phone://+49.201.491621
http://spunk.dnsalias.org
http://www.linuxdj.com/audio/lad/

On Wed, 30 Jan 2002, [iso-8859-1] J=F6rn Nettingsmeier wrote:

> > > glame one, but somehow it only outputs half a second or so of white
> > > noise, then falls silent.
> > > what am i missing here ?
> >
> > You have to put the repeat filter behind it and enter a duration for
> > that it should output noise, or you could use the ladspa white noise
> > plugin.
>
> i see. is there a reason for this behaviour ?

Modularity ;) But of course we may change that, given reasonable
behavior wrt network finish.

> normally i'd want an oscillator or noise source to go on endlessly.
> would it be complicated to make this the behaviour for duration =3D=3D 0?

No, but you might as well just use 1e30 then :) Would it be reasonable
then to change the repeat time to default to 0.0 (i.e. endless)?

> > > and what does the "position" slider do ?
> >
> > With the position slider you can define the position of a track in a 2D
> > soundfield. Imagine a circle with angles defined from -PI/2(-90 degrees=
)
> > to PI/2(90 degrees). -PI/2 pins the track to the left and +PI/2 to the
> > right.
>
> yes.. i remember i laughed my head off on linuxtag when i realized
> you were using rads as a panning unit :)

:))

> just forgot. anyway, how about "panorama" or "left<->right" as a
> slider label ?

certainly possible.

> one more thing:
>
> right now i'm using a spare sound card as an outboard effect for my
> mixing desk. i build a filternetwork with gverb, choose hw1:0 as
> alsa input and output device, and everthing works fine.
>
> however, the latency is a bit high for my taste.
> i measured 46 milliseconds, which is a bit much except maybe for
> ballad reverbs. i wonder, is that a hardware constraint of my crappy
> card (ens1371) or can i reduce the buffer size that glame uses ?
> maybe you can give me a hint where to look in the sources ?
>
> i tried the global settings dialog, but it has no effect, and it
> does not allow for card-specific settings anyway. the proper place
> for this is probably the "alsa-input->properties" widget...

No, the global settings dialog is what you are looking for. Just
change the "Size hint for audio buffers [samples]" to 128 (or 64)
and you should get reasonable latency (read: ~5ms) - dependent
on the intelligence and internal buffering of the plugins, of course.
At least that is the latency I get with my ISA SB AWE / via onboard
sound (yepp, not full-duplex, but sampling from sb, playback on via,
using OSS).

> btw, i've done about 2 cds worth of editing now with the new glame,
> and i must say it has not crashed a single time for me yet. one can
> kill it doing nasty things to the filternetwork, but other than
> that, it's been rock solid for me. great work !

Hope so. Whats these "nasty" things? We might want to fix those
issues, too.

Richard.

--
Richard Guenther <richard.guenther@...>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

On Wed, Jan 30, 2002 at 04:35:43PM +0100, Richard Guenther wrote:
> Modularity ;) But of course we may change that, given reasonable
> behavior wrt network finish.

As far as I can tell, the additional repeat node does not introduce
performance issues. Therefore, I don't see a point duplicating the
repeat code in each generator plugin. My vote goes for renaming the
existing plugins to eg. noise-single, noise-oneshot,
noise-iknowwhatimdoing, __noise, or whatever. Maybe even shove them off
to a different section in the menu. 'noise' itself will then be a
network of 'noise-single' plus 'repeat'. This provides users with sane
default behaviour without loosening our modular approach.

*nold.

On Wed, 30 Jan 2002, Daniel Kobras wrote:

> On Wed, Jan 30, 2002 at 04:35:43PM +0100, Richard Guenther wrote:
> > Modularity ;) But of course we may change that, given reasonable
> > behavior wrt network finish.
> 
> As far as I can tell, the additional repeat node does not introduce
> performance issues. Therefore, I don't see a point duplicating the
> repeat code in each generator plugin. My vote goes for renaming the
> existing plugins to eg. noise-single, noise-oneshot,
> noise-iknowwhatimdoing, __noise, or whatever. Maybe even shove them off
> to a different section in the menu. 'noise' itself will then be a
> network of 'noise-single' plus 'repeat'. This provides users with sane
> default behaviour without loosening our modular approach.

Yes, but what about making repeat repeating endless for time set
to zero seconds? And making that default?

Richard.

--
Richard Guenther <richard.guenther@...>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

On Wed, Jan 30, 2002 at 06:14:51PM +0100, Richard Guenther wrote:
> Yes, but what about making repeat repeating endless for time set
> to zero seconds? And making that default?

Ah, this is fine by me.

*nold.

On Wed, 2002-01-30 at 18:22, Daniel Kobras wrote:
> On Wed, Jan 30, 2002 at 06:14:51PM +0100, Richard Guenther wrote:
> > Yes, but what about making repeat repeating endless for time set
> > to zero seconds? And making that default?
> 
> Ah, this is fine by me.

No worries mates, this is kewl :)

Cheers,
Ibookmag :)

On Sun, 20 Jan 2002, ephemeron wrote:

> I have an mpeg video whose audio I need to synchronize. The solution I'm
> thinking of is to stretch or lengthen the playing time of the audio. I'm
> assuming it loses sync at a constant rate. My question: can glame
> stretch the total playing time of the sound file ( .wav format) I'll get
> from demultiplexing the mpeg video?

No, this is currently not possible. Somebody needs to do a plugin
for this - maybe mag can elaborate.

Richard.

--
Richard Guenther <richard.guenther@...>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/

> On Sun, 20 Jan 2002, ephemeron wrote:
>=20
>> I have an mpeg video whose audio I need to synchronize. The solution
>> I'm thinking of is to stretch or lengthen the playing time of the
>> audio. I'm assuming it loses sync at a constant rate. My question: can
>> glame stretch the total playing time of the sound file ( .wav format)
>> I'll get from demultiplexing the mpeg video?
>=20
> No, this is currently not possible. Somebody needs to do a plugin
> for this - maybe mag can elaborate.

You can use sox for this purpose, here is part of the man sox;

=20
      stretch factor [window fade shift fading]
                 Time  stretch  file  by  a  given factor. Change
                 duration without affecting the pitch.  factor of
                 stretching:  >1.0  lengthen,  <1.0 shorten dura=AD
                 tion.  window size is in ms.  Default  is  20ms.
                 The  fade option, can be "lin".  shift ratio, in
                 [0.0 1.0]. Default depends  on  stretch  factor.
                 1.0  to  shorten,  0.8  to lengthen.  The fading
                 ratio, in [0.0 0.5].  The  amount  of  a  fade's
                 default depends on factor and shift.

Kalou

On Mon, 7 Jan 2002, [iso-8859-1] Martin Glaser wrote:
> --- Richard Guenther <rguenth@...> wrote:
> > > 9. Bei gr=F6=DFeren Spuren (mehrere Minuten) dauert der Anzeigeaufbau
> > > im
> > > Waveeditor doch schon recht lange, vor allem, wenn man die ganze
> > > Spur
> > > in der =DCbersicht sehen m=F6chte. Reicht es nicht nur kleinere
> > > "H=E4ppchen"
> > > der Spur zu lesen und auszuwerten?
> >
> > Well - if you want to see everything, we need to read everything in.
> >
>
> No, I don't think so. Imagine having a track with a length of 40
> minutes. I want to see the complete thing, just for an overview. The
> width in the window is e. g. 400 pixels. Each pixel is then 1/10
> minute, that is 6 seconds. I don't think that it is necessary to
> calculate the maximum of 6 seconds music for this "pixel bar". Could be
> enough to calculate the maximum of 20 ms (supposing 50 Hz is the lowest
> frequency) in the middle of these 6 seconds. In that case you do not
> have to read the whole data from disc. Sure, it's not showing the exact
> maximum, maybe the is a higher maximum nearby, but what would I do with
> this exact information in such an overview window?

Umm well, if you dont want exact information and instead do what you
suggest, we can just show random data, too - that would even be faster.
The only thing one _can_ do is to keep an (exact) multiresolution
representation of the data. But that is costly in terms of initial
generation and updating. So I dont think its worth it.

> I have this idea because I have seen other programs that are quicker
> when generating the overview. Maybe my idea is not working, but you
> could try it...

Usually those programs generate a peak file at startup/import, so the
time is spent there. Of course this time is spent only once, so what
we can do is improve caching in the wavewidget (which is rather weak
at the moment).

Richard.

--
Richard Guenther <richard.guenther@...>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

> On Mon, 7 Jan 2002, [iso-8859-1] Martin Glaser wrote:
> >
> > No, I don't think so. Imagine having a track with a length of 40
> > minutes. I want to see the complete thing, just for an overview.
> > The
> > width in the window is e. g. 400 pixels. Each pixel is then 1/10
> > minute, that is 6 seconds. I don't think that it is necessary to
> > calculate the maximum of 6 seconds music for this "pixel bar".
> > Could be
> > enough to calculate the maximum of 20 ms (supposing 50 Hz is the
> > lowest
> > frequency) in the middle of these 6 seconds. In that case you do
> > not
> > have to read the whole data from disc. Sure, it's not showing the
> > exact
> > maximum, maybe the is a higher maximum nearby, but what would I do
> > with
> > this exact information in such an overview window?
> 
> Umm well, if you dont want exact information and instead do what you
> suggest, we can just show random data, too - that would even be
> faster.
> The only thing one _can_ do is to keep an (exact) multiresolution
> representation of the data. But that is costly in terms of initial
> generation and updating. So I dont think its worth it.

I agree, that keeping an exact multiresolution representation of the
data is not worth it.

But looking at a shorter sample for generating the data for display is
not like generating random data. What is the information of the exact
maximum in 6 seconds of a signal worth? It's enough to see roughly
what's going on (passages with silence, loud passages, quiet passages).

Maybe 20 ms is too short. A longer period could be taken. Maybe it is
better to read several times 20 ms in the 6 seconds of data. Going down
to a lowest frequency of 20 Hz would mean to look at 50 ms of data.

And there must be a point (a certain zoom stage), at which the software
switches from exact display to the more roughly working algorithm.

All this needs a bit trying around. From the users's point of view the
time needed for displaying an overview should not be more than a few
seconds. Looking at a track with a length between 1 and 5 minutes
should not take longer than 2 seconds.

> 
> > I have this idea because I have seen other programs that are
> > quicker
> > when generating the overview. Maybe my idea is not working, but you
> > could try it...
> 
> Usually those programs generate a peak file at startup/import, so the
> time is spent there. Of course this time is spent only once, so what
> we can do is improve caching in the wavewidget (which is rather weak
> at the moment).

Yes, that's right. But those programs are faster generating their peak
file at startup than GLAME showing an overview and I can see that their
signal representation is "rougher".

Another thing about selection: I wrote you, that I intuitively
sometimes expect another behaviour than what happens, and you answered
that you need a more exactly description. I needed thinking about it
and that's what came out:

1. If I try to select something starting from the very beginning of the
track or if I try to select something that needs to end with the very
end of the track, it does not work. A small bit is missing in the
selection. Zooming in reveals the problem. I can try to work around
this problem selecting everything first and changing one of the
borders, but then I run into the problem in point 2:

2. I can change the borders of a selection using the shift key. If the
mouse cursor is outside the selection when starting to change
everything works as expected: Being outside the selection to the right
side will change the right border of the selection and visa versa with
the left side. But when my mouse is inside the selection when I start a
change I cannot figure out a rule. I think it should change the right
resp. left border depending whether the mouse is right resp. left from
the middle of the selection.

3. It would be helpful to have a display of the time the selection is
going from and too and where the current position is (in min:sec:ms and
in samples).

Martin


__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Ihre E-Mail noch individueller? - http://domains.yahoo.de

> On Mon, 7 Jan 2002, [iso-8859-1] Martin Glaser wrote:
> >
> > No, I don't think so. Imagine having a track with a length of 40
> > minutes. I want to see the complete thing, just for an overview.
> > The
> > width in the window is e. g. 400 pixels. Each pixel is then 1/10
> > minute, that is 6 seconds. I don't think that it is necessary to
> > calculate the maximum of 6 seconds music for this "pixel bar".
> > Could be
> > enough to calculate the maximum of 20 ms (supposing 50 Hz is the
> > lowest
> > frequency) in the middle of these 6 seconds. In that case you do
> > not
> > have to read the whole data from disc. Sure, it's not showing the
> > exact
> > maximum, maybe the is a higher maximum nearby, but what would I do
> > with
> > this exact information in such an overview window?
> 
> Umm well, if you dont want exact information and instead do what you
> suggest, we can just show random data, too - that would even be
> faster.
> The only thing one _can_ do is to keep an (exact) multiresolution
> representation of the data. But that is costly in terms of initial
> generation and updating. So I dont think its worth it.

I agree, that keeping an exact multiresolution representation of the
data is not worth it.

But looking at a shorter sample for generating the data for display is
not like generating random data. What is the information of the exact
maximum in 6 seconds of a signal worth? It's enough to see roughly
what's going on (passages with silence, loud passages, quiet passages).

Maybe 20 ms is too short. A longer period could be taken. Maybe it is
better to read several times 20 ms in the 6 seconds of data. Going down
to a lowest frequency of 20 Hz would mean to look at 50 ms of data.

And there must be a point (a certain zoom stage), at which the software
switches from exact display to the more roughly working algorithm.

All this needs a bit trying around. From the users's point of view the
time needed for displaying an overview should not be more than a few
seconds. Looking at a track with a length between 1 and 5 minutes
should not take longer than 2 seconds.

> 
> > I have this idea because I have seen other programs that are
> > quicker
> > when generating the overview. Maybe my idea is not working, but you
> > could try it...
> 
> Usually those programs generate a peak file at startup/import, so the
> time is spent there. Of course this time is spent only once, so what
> we can do is improve caching in the wavewidget (which is rather weak
> at the moment).

Yes, that's right. But those programs are faster generating their peak
file at startup than GLAME showing an overview and I can see that their
signal representation is "rougher".

Another thing about selection: I wrote you, that I intuitively
sometimes expect another behaviour than what happens, and you answered
that you need a more exactly description. I needed thinking about it
and that's what came out:

1. If I try to select something starting from the very beginning of the
track or if I try to select something that needs to end with the very
end of the track, it does not work. A small bit is missing in the
selection. Zooming in reveals the problem. I can try to work around
this problem selecting everything first and changing one of the
borders, but then I run into the problem in point 2:

2. I can change the borders of a selection using the shift key. If the
mouse cursor is outside the selection when starting to change
everything works as expected: Being outside the selection to the right
side will change the right border of the selection and visa versa with
the left side. But when my mouse is inside the selection when I start a
change I cannot figure out a rule. I think it should change the right
resp. left border depending whether the mouse is right resp. left from
the middle of the selection.

3. It would be helpful to have a display of the time the selection is
going from and too and where the current position is (in min:sec:ms and
in samples).

Martin


__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Ihre E-Mail noch individueller? - http://domains.yahoo.de

On Tue, 8 Jan 2002, [iso-8859-1] Martin Glaser wrote:

> I agree, that keeping an exact multiresolution representation of the
> data is not worth it.
>
> But looking at a shorter sample for generating the data for display is
> not like generating random data. What is the information of the exact
> maximum in 6 seconds of a signal worth? It's enough to see roughly
> what's going on (passages with silence, loud passages, quiet passages).
>
> Maybe 20 ms is too short. A longer period could be taken. Maybe it is
> better to read several times 20 ms in the 6 seconds of data. Going down
> to a lowest frequency of 20 Hz would mean to look at 50 ms of data.
>
> And there must be a point (a certain zoom stage), at which the software
> switches from exact display to the more roughly working algorithm.
>
> All this needs a bit trying around. From the users's point of view the
> time needed for displaying an overview should not be more than a few
> seconds. Looking at a track with a length between 1 and 5 minutes
> should not take longer than 2 seconds.

Hmm, one major performance problem is that we update the display
interleaved for all tracks, but the data is not stored interleaved. I also
agree that showing the maximum sample value is not of much value - if its
"correct" or not. We rather need to do calculate some rms value instead.

> > Usually those programs generate a peak file at startup/import, so the
> > time is spent there. Of course this time is spent only once, so what
> > we can do is improve caching in the wavewidget (which is rather weak
> > at the moment).
>
> Yes, that's right. But those programs are faster generating their peak
> file at startup than GLAME showing an overview and I can see that their
> signal representation is "rougher".

> Another thing about selection: I wrote you, that I intuitively
> sometimes expect another behaviour than what happens, and you answered
> that you need a more exactly description. I needed thinking about it
> and that's what came out:
[..]

Ok, I noticed these things, too - and delayed fixing these issues until
I have time to finish the rewrite of the wavewidget (which will allow
for multiresolution at least at the caching level).

Seems work on the waveedit widget rewrite now raised in priority...

Richard.

--
Richard Guenther <richard.guenther@...>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

> On Mon, 7 Jan 2002, [iso-8859-1] Martin Glaser wrote:
> >
> > No, I don't think so. Imagine having a track with a length of 40
> > minutes. I want to see the complete thing, just for an overview.
> > The
> > width in the window is e. g. 400 pixels. Each pixel is then 1/10
> > minute, that is 6 seconds. I don't think that it is necessary to
> > calculate the maximum of 6 seconds music for this "pixel bar".
> > Could be
> > enough to calculate the maximum of 20 ms (supposing 50 Hz is the
> > lowest
> > frequency) in the middle of these 6 seconds. In that case you do
> > not
> > have to read the whole data from disc. Sure, it's not showing the
> > exact
> > maximum, maybe the is a higher maximum nearby, but what would I do
> > with
> > this exact information in such an overview window?
> 
> Umm well, if you dont want exact information and instead do what you
> suggest, we can just show random data, too - that would even be
> faster.
> The only thing one _can_ do is to keep an (exact) multiresolution
> representation of the data. But that is costly in terms of initial
> generation and updating. So I dont think its worth it.

I agree, that keeping an exact multiresolution representation of the
data is not worth it.

But looking at a shorter sample for generating the data for display is
not like generating random data. What is the information of the exact
maximum in 6 seconds of a signal worth? It's enough to see roughly
what's going on (passages with silence, loud passages, quiet passages).

Maybe 20 ms is too short. A longer period could be taken. Maybe it is
better to read several times 20 ms in the 6 seconds of data. Going down
to a lowest frequency of 20 Hz would mean to look at 50 ms of data.

And there must be a point (a certain zoom stage), at which the software
switches from exact display to the more roughly working algorithm.

All this needs a bit trying around. From the users's point of view the
time needed for displaying an overview should not be more than a few
seconds. Looking at a track with a length between 1 and 5 minutes
should not take longer than 2 seconds.

> 
> > I have this idea because I have seen other programs that are
> > quicker
> > when generating the overview. Maybe my idea is not working, but you
> > could try it...
> 
> Usually those programs generate a peak file at startup/import, so the
> time is spent there. Of course this time is spent only once, so what
> we can do is improve caching in the wavewidget (which is rather weak
> at the moment).

Yes, that's right. But those programs are faster generating their peak
file at startup than GLAME showing an overview and I can see that their
signal representation is "rougher".

Another thing about selection: I wrote you, that I intuitively
sometimes expect another behaviour than what happens, and you answered
that you need a more exactly description. I needed thinking about it
and that's what came out:

1. If I try to select something starting from the very beginning of the
track or if I try to select something that needs to end with the very
end of the track, it does not work. A small bit is missing in the
selection. Zooming in reveals the problem. I can try to work around
this problem selecting everything first and changing one of the
borders, but then I run into the problem in point 2:

2. I can change the borders of a selection using the shift key. If the
mouse cursor is outside the selection when starting to change
everything works as expected: Being outside the selection to the right
side will change the right border of the selection and visa versa with
the left side. But when my mouse is inside the selection when I start a
change I cannot figure out a rule. I think it should change the right
resp. left border depending whether the mouse is right resp. left from
the middle of the selection.

3. It would be helpful to have a display of the time the selection is
going from and too and where the current position is (in min:sec:ms and
in samples).

Martin


__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Ihre E-Mail noch individueller? - http://domains.yahoo.de

On Tue, 8 Jan 2002, Martin Glaser wrote:

> Another thing about selection: I wrote you, that I intuitively
> sometimes expect another behaviour than what happens, and you answered
> that you need a more exactly description. I needed thinking about it
> and that's what came out:
> 
> 1. If I try to select something starting from the very beginning of the
> track or if I try to select something that needs to end with the very
> end of the track, it does not work. A small bit is missing in the
> selection. Zooming in reveals the problem. I can try to work around
> this problem selecting everything first and changing one of the
> borders, but then I run into the problem in point 2:

I'll try fixing this. Note that selecting the beginning of the track
seems to work, just for the end it "fails" - is this correct?

> 2. I can change the borders of a selection using the shift key. If the
> mouse cursor is outside the selection when starting to change
> everything works as expected: Being outside the selection to the right
> side will change the right border of the selection and visa versa with
> the left side. But when my mouse is inside the selection when I start a
> change I cannot figure out a rule. I think it should change the right
> resp. left border depending whether the mouse is right resp. left from
> the middle of the selection.

The selection, if modified/created with the SHIFT modifier is set to
from the _marker_ position to the position you clicked to, regardless of
any existing selection. So it may be not what you expected, but it seems
at least consistent.

> 3. It would be helpful to have a display of the time the selection is
> going from and too and where the current position is (in min:sec:ms and
> in samples).

Umm, yes. Current position means the marker position? Or the actual value
of the hat in the ruler?

Richard.

--
Richard Guenther <richard.guenther@...>
PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
WWW: http://www.anatom.uni-tuebingen.de/~richi/

--- Richard Guenther <rguenth@...> schrieb: >
On Tue, 8 Jan 2002, Martin Glaser wrote:
> 
> > Another thing about selection: I wrote you, that I intuitively
> > sometimes expect another behaviour than what happens, and you
> > answered
> > that you need a more exactly description. I needed thinking about
> > it
> > and that's what came out:
> > 
> > 1. If I try to select something starting from the very beginning of
> > the
> > track or if I try to select something that needs to end with the
> > very
> > end of the track, it does not work. A small bit is missing in the
> > selection. Zooming in reveals the problem. I can try to work around
> > this problem selecting everything first and changing one of the
> > borders, but then I run into the problem in point 2:
> 
> I'll try fixing this. Note that selecting the beginning of the track
> seems to work, just for the end it "fails" - is this correct?
> 

I'm not sure. And I cannot check at the moment, because I'm not at
home. What I did, was cutting a piece out of a song and applying a
Fade-In at the beginning and a Fade-Out at the end. I remember for the
end, that there was a final click, but not for the beginning.

> > 2. I can change the borders of a selection using the shift key. If
> > the
> > mouse cursor is outside the selection when starting to change
> > everything works as expected: Being outside the selection to the
> > right
> > side will change the right border of the selection and visa versa
> > with
> > the left side. But when my mouse is inside the selection when I
> > start a
> > change I cannot figure out a rule. I think it should change the
> > right
> > resp. left border depending whether the mouse is right resp. left
> > from
> > the middle of the selection.
> 
> The selection, if modified/created with the SHIFT modifier is set to
> from the _marker_ position to the position you clicked to, regardless
> of
> any existing selection. So it may be not what you expected, but it
> seems
> at least consistent.
> 
Aha. Does that mean there is no way to modify a selection?

> > 3. It would be helpful to have a display of the time the selection
> > is
> > going from and too and where the current position is (in min:sec:ms
> > and
> > in samples).
> 
> Umm, yes. Current position means the marker position? Or the actual
> value
> of the hat in the ruler?
> 
The marker position.

Martin


__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Ihre E-Mail noch individueller? - http://domains.yahoo.de

On Fri, 11 Jan 2002, [iso-8859-1] Martin Glaser wrote:

> > > 2. I can change the borders of a selection using the shift key. If
> > > the
> > > mouse cursor is outside the selection when starting to change
> > > everything works as expected: Being outside the selection to the
> > > right
> > > side will change the right border of the selection and visa versa
> > > with
> > > the left side. But when my mouse is inside the selection when I
> > > start a
> > > change I cannot figure out a rule. I think it should change the
> > > right
> > > resp. left border depending whether the mouse is right resp. left
> > > from
> > > the middle of the selection.
> >
> > The selection, if modified/created with the SHIFT modifier is set to
> > from the _marker_ position to the position you clicked to, regardless
> > of
> > any existing selection. So it may be not what you expected, but it
> > seems
> > at least consistent.
> >
> Aha. Does that mean there is no way to modify a selection?

You can, by dragging the left/right edges of the selection (the curser
will become different, if you get to the vicinity of the edges). This
works for moving the marker, too.

Richard.

--
Richard Guenther <richard.guenther@...>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/

On Mon, 7 Jan 2002, ALP wrote:

> I am running Mandrake 8.0, kernal 2.4.2.
> The following was cut and pasted. Please excuse the format!
> I have spent many many hours over a number of days trying to get glame
> working on my
> system. The problem is getting audio output. It just doesn't want to play
> anything from within Gnome or KDE.
> I believe I installed Glame from within KDE. Is this good or bad?
> I have both KDE and Gnome on my setup and can choose either at login.
>
> Does Glame only work from one of these desktops?

Yes, Glame does not care about the desktop you're running. But read on...

> Athlon 650 with 256M ram.
> Onboard sound (AC'97 V2.1 CODEC compliant)
> HardDrake correctly identifies sound as
> Vendor: VIA Technologies, Inc.
> Model: VT82C686 [Apollo Super AC97/Audio]
> Kernel Module: via82cxxx_audio
> Bus Type: PCI

Should be fine - thats what I'm using, too. You're using the kernel
driver (oss) I assume.

> I am very new to Linux but can follow explicit directions.
> Tips on setting things up without saying HOW to actually do so (or where to
> look, what application to use) are very fustrating for me.

Ok, I always wanted to clean up the audio settings dialog. Maybe a
"test" button is helpful, too...

> SETTINGS..
> in the audio I/O section there are 5 windows.

You should for your oss setup choose oss_audio_in/oss_audio_out for
the input/output plugins and the appropriate devices for
recording/playback (I use /dev/dsp for recording and /dev/dsp1 for
playback, if I remember correctly - if this doesnt work try /dev/dsp for
playback, too - but that may disable full duplex support).

This setup should work, BUT (read on)

> Kmix works with my current setup.
> KDE media player works and plays the wav files I wish to edit in glame.
> However I cannot get any sound from glame.
> When trying to play a wav file( waveform is seen in edit window).
> I will have my kmix program up and running.
>
> Leaving the audio I/O settings in the origional settings i get a
> "Cannot play wave audio-out: Could not open audio device".
>
> Changing both input and output plugins to oss.. gives same error.

You seem to have a program running that blocks the audio device. This
may be caused by the esd sound daemon (which gnome uses) or by the
arts sound daemon (which kde uses). Try issuing killall esd (or
killall artsd) from an xterm before trying to play.

> Changing both plugins for esd..."Cannot play wave audio-out:
> couldn't open esd-socket connection"

For the esd_audio_out plugin the device needs to be set to "" (i.e.
an empty string, nothing in the edit field).

> Changing the output plugin to alsa and the input to audio_in gives
> "Cannot play wave audio-out: Could not open audio device".

For the alsa_audio_out plugin the device should read something
like "plughw:0,0"

Tell me, if anything worked, so we can at least improve the
documentation.

Richard.

--
Richard Guenther <richard.guenther@...>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/
The GLAME Project: http://www.glame.de/