Re: [Traverso-devel] news

[Reinhard Amersberger]

> -----Ursprüngliche Nachricht-----
> Von: address@hidden
> Gesendet: 07.02.08 14:49:46
> An: address@hidden
> Betreff: Re: [Traverso-devel] news


> 
> Hi,
> 
> > > Yes, Traverso doesn't do autoconnection of jack ports. If you have an
> > > idea how this can be handled, please mention it on the traverso-devel,
> > > the forums or bugtracker.
> >
> > hehe, this was my intention - I just used the wrong send-to address ;)
> > well, I don't know how to code this, but qtractor or muse for example do
> > the automatic connection, so maybe you can have a look in their code?
> 
> It's not about the coding, but the 'intended behavior'. Most people dislike 
> automatic connection, since they make their own (advanced) connections to 
> establish a routing which is most likely different then that from the 
> autoconnect.
> 
> So if you _want_ autoconnection, then it's most likely you use Traverso as 
> the 
> _only_ jack client, and have the alsa ports connected to the traverso ports, 
> in which case I would _highly_ recommend to _not_use_jack_ but the Alsa 
> driver instead :)
> 
> Anyways, you can of course add a bug/wish to the bug tracker for jack 
> autoconnection, so I can't forget about that. (with addition of an 'use 
> autoconnect' preference option for the Jack Driver)

yep, this seems a good solution imho.

> 
> > ok, sounds reasonable ...
> > btw - is it possible to add plugins to a clip?
> 
> Technically yes, but the GUI needs to be updated. There are some ideas 
> floating around how we can best handle the visualization for audio/track 
> plugins.
> 
> > > > And what about [ W E ] and [ E R ] ? I REALLY MISSING IT!!!! ;)
> > >
> > > Hmyeah, I figured that it's a little bit overkill, and moved to [ E ]
> > > only, but if you think they still serve a good purpose, then I can sure
> > > re-add these :)
> >
> > yeah, personally I would like to have since I don't like the actual
> > behaviour that the clip edge jumps directly to the cursor position when
> > doing [ E ] although I actually wanted to adapt it JUST A BIT...
> 
> ah, but these actions would not change that!! I mean, if [ E ] would not let 
> the edge jump to the mouse cursor, then it would be OK too, right ?

for me yes, but in some situations it's also a really handy feature if the edge 
jumps to the cursor position. So best would be to have both ;)

> 
> > > I'm not sure if it adds any value to add [ Z ] + <up/dow arrow> ?
> > > If it does, can you please explain what you have in mind?
> >
> > e.g.
> > zoom in vertical == [ Z ]  <up arrow>
> > zoom out vertical == [ Z ]  <down arrow>
> 
> Your right hand holds the mouse most of the time, so lifting it up to use the 
> arrow keys is slower then using the scroll wheel?

:) personally I just don't like the scroll wheel ;)

> But sure, it would be a matter of copy pasting the keymap definition for this 
> one, replacing mousewheel with up/downarrow :)
> 
> > zoom in horizontal ==  [ Z ]  <right arrow>
> > zoom out horizontal ==  [ Z ]  <left arrow>
> > zoom full in horizontal == [ Z ] <<left/right arrow>>
> > zoom full out vertical == [ Z ]  <up/down arrow>
> > zoom to fit screen == [ Z ] < 0 > or [ Z 0 ]
> > revert zoom to last used zoom factor == << Z >>
> 
> Yes, they can be added, now that arbitrary zoom levels are possible, though 
> it's still not finished yet :(
> On the other hand, the right hand lifting and moving aspect comes to mind 
> here 
> as well. Why not add them to the 'context menu' of Zoom? So it becomes [ Z ] 
> + <right mouse button>, select option, done.
> Me thinks, that's faster :)

hhmm, you  can give it a try, but I still vote for the arrows... ;)

greetings
reinhard