Hi Rui,
I was wondering about the new jackd auto startup qtractor is now capable of. How does this work exactly? Are you using the last used qjackctl config (.jackdrc) file? When are you planning to eventually incorporate some of the qjackctl settings within qtractor? :)
Ah, another idea just sprung to my feeble mind: I guess I'm in a semi-creative mood this evening. ;)
When selecting an input source for a qtractor track, what about scanning the jackd connections for external programs (audio or MIDI), such as qsampler and qsynth for example. Then add that to the list of available input options, and connect the qtractor input(s) transparently. thus making it easier to work with external sound generating jackd compatible apps. This might solve some of the recent discussion issues regarding Assignable I/O without building in any direct support for qsynth/qsampler, or anything else, for that matter.
However, I realize ideas are much easier than working code. ;)
Just a thought.
Thanks,
Lexridge
Re: jackd autostart
In fact, the jackd auto-start is a jackd option feature. Yes, it uses the
~/.jackdrcwhich is conveniently written by qjackctl everytime you start jackd through it. This~/.jackdrcfile contains the exact command line that should be invoked when auto-starting jackd, so its mechanics are very straight forward.Basic settings for starting jackd under Qtractor control is in the MTDL (Mighty TODO List:).
About the assignable I/O issue. I reckon your wishes to make things easier or user-friendlier. However I'm having some difficulty in realizing those wishes ;) all jack/alsa-seq applications are accessible through the connections dialog (the one cloned from qjackctl;) so how can I make it even easier without making some kind of hardwire to some special application (eg. qsynth, qsampler) ? Maybe I'm just being too stubborn and missing the question in point here. Would you elaborate on that? :)
Cheers
--
rncbc aka Rui Nuno Capela
Assignable I/O
Personally, the connections dialog works fine for me, but I was just trying to come up with a solution to the suggestions that both Alex and Domenik were talking about. At least that is the way I understood their requests.
I don't think any hardwiring to any external program would be necessary to pull this off (unless our terminology of hardwiring is in misunderstanding).
* When creating a new track, be it audio or MIDI, scan the jack apps list, once for MIDI apps, and once for Audio apps, creating an array for each. This array might even include the full path to the app that is connected to jackd.
* In the Track dialog, when selecting the input, fill that widget with the results of the jackd apps scan. If it's an audio track, include all the audio programs that are connected to jackd. And the same if it's a MIDI track.
* So now, not only is the normal "Master" present as an input choice, but also the running audio apps are also available.
* Select an app from this list, such as Qsampler. This would then auto patch the connections dialog to said track input.
* If possible to also capture the program's run path, that could be stored in the project file, and the external apps could also then be automatically restarted when loading a project that includes them.
This 'might' be a very clever way to make it seem as if things are hardwired, when in fact, they are not. :))
Does this make more sense?
Lexridge
Re: Assignable I/O
Somehow I'm getting the whole idea but, ... my twisted mind is resolving the question in the following manner. You know the rule, the simpler and the cheaper gets my vote :) As I read it, the whole issue seems to be about making it easier to access one assigned track inputs and/or outputs. I believe the best way to make this accessible is having an extended track context menu, which will refer to the current selected track. New menu items might include:
I guess these ones will facilitate things a bit. I'm sure it's not the ideal answer, but, as said, maybe it's the least pervasive.
Ah, some more Track menu items, that are now popping from the top of my head, not necessarily related to this topic, but cope with the recent suggestion and implementation of those configurable keyboard shortcuts (inferred from Alex Stone's request):
Ah, and yet some more, this time under the View menu:
However probably, all this will get post-0.1.1, which I'm thinking on throwing out this week-end.
What you think?
--
rncbc aka Rui Nuno Capela
Re: Assignable I/O, as Menu Items
I've read this many times, trying to get a feel for it before replying. Here is my opinion:
- Making some of this as menu items would have some advantages, such as they could be assigned to a keyboard command. All in all, I personally find lots of menus quarky to navigate through. The Previous, Next, Move Up/Down would be useful to me. I can't see much point in Mute or Solo. However, Mute and Solo should be assignable to a keyboard command, nonetheless. I just cannot see anyone navigating through a menu to mute or solo a track.
- Zoom would be a very good item to add, hence again, making it keyboard shortcut assignable. This would be nice, as the Zoom icons are very difficult to see on high res monitors, as previously noted by Wolfgang.
- Regarding the menu items for Inputs and Outputs, as I understand it. I think doing I/O as a menu item may be more complicated to program, and also actually use, than just using the Track Properties dialog that already exists. Once the input is set in a session, it is unlikely to change again, at least in my case. However, the Track Properties should also contain a Next/Previous Track selector, making it easy to simply scroll through each track's properties within the Track Properties dialog.
Wow, I think we've opened a can of worms here. ;)
Take care,
Lexridge
Re: Assignable I/O, as Menu Items
The main and almost unique advantage of having these new menu items are just because then you may have keyboard shortcuts of your choice for each action. Now that every keyboard shortcut is freely configurable, it makes sense to have those navigation and toggling actions just one key away ;) So, this is for user convenience, no big trouble in coding. It will be the first thing to get done once this weekend release gets out ;)
Back on the inputs and outputs issue, my suggestion was not about making connection management from the menu. No, no, no :) Look: the way I suggested just deals as a shortcut to the Connections window, much in the like to what is already done for buses in the Mixer widget: for example, selecting Track Outputs will command the Connections to show up the current assigned output bus ports which apply indirectly for that track. This is also dead easy to implement (ok, it will take an hour or two, but no big deal) so I guess there's no can and no worm holes here :)
Cheers
--
rncbc aka Rui Nuno Capela
Re: Menu Items
This has just been commited to CVS HEAD (qtractor 0.1.1.865+)
Track menu has been granted new accessible actions:
View menus have also these new accessible actions:
Enjoy (the possibility of custom keyboard shortcuts).
--
rncbc aka Rui Nuno Capela
Re: More Menu Items
More of the same, on CVS HEAD (qtractor 0.1.1.866+)
Track menu has some more new actions:
Enjoy && hope you don't hose it all as keyboard shortcuts:o).
--
rncbc aka Rui Nuno Capela
More Regarding More Menu Items
Just got the latest cvs compiled here, and so far, all menu additions are working. :) I've been busy assigning, and re-assigning key commands, now I'm ready to put it to some real use.
Nice work, as usual! :)
Lexridge
Re: Clip Split command?
lexridge,
Hope you feel comfortable with the new shortcut possibilities ;)
Now to something a bit different.
I was wandering about implementing that long due split-clip command you asked for, remember? However, I have some doubts: how does it should work, regarding the target point where the split is to be made:
a) should it be done directly at the mouse pointer position, or
b) on the current edit-head position? (fyi. the edit-head is the left blue vertical line), and
c) should the split apply to all clips vertically or just the one in the current (pointed) track?
Byee
--
rncbc aka Rui Nuno Capela
Clip Splitting
I too have thought about this for some time. It needs to function with as little user input as possible.
I believe the most intuitive way to do this, would be to have the Clip one wants to split selected (highlighted), and this could even work for multiple, stacked selected clips. Then, the split command would split all clips at the master playback head. If the playback head is not over any selected clips, then no splitting could actually occur.
The reason I chose the playback head as the split point is it would seem to be easier to split at very tight samples, since I can use the playback head to hear it. The problem with using the edit-head is I would need to first, find my split point with the playback head, then move the edit-head to the same point. Too much redundancy IMO. I also don't see any point in having the track selected, just the Clip(s).
What do you think?
EDIT: Having multiple stacked clips selected and all being split is probably asking to much. As long as the play head is parked where the split point takes place, It would be easy enough to just selected the next clip, split it, and so on.
cheers,
Lexridge
Post new comment