Main menu
You are here
jackd autostart
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
Re: Clip Split command (DONE)
OK, the clip split command has finally entered the stage (see Edit/Clip/Split) and the semantics is just simple as you reasoned: splitting occurs on the current (selected) clip at the current playhead position (red cursor line) as an immediate command (no questions asked).
As in latest CVS HEAD (qtractor 0.1.1.891+)
Eagerly waiting for your assessment :)
Byee.
--
rncbc aka Rui Nuno Capela
Assignable I/O
lexrigde wrote:
* Select an app from this list, such as Qsampler. This would then auto patch the connections dialog to said track input.
Why then value what I have request before?
Qsampler allow to create a new giga intruments, assignable audio-midi out connection to the Linuxasmpler, editing the Volume, Pan-Pot and effect sends.
Qtractor we have right now the same features, under the track propiety is possible select the Instruments mode ( there just to add the Loader giga script to LS), midi Out is available, under the Mixer is available the Volume, Mute, Pan-pot, all the same fatures that have the Qsampler.
Instead to use the program change feature, qtractor have just to load in the track the desidered giga sounds, instead to open Qsampler, add the all instruments, setups, Jack routing...
All can be saved and integrated on the Qtractor session, without recall the external Qsampler.
more easy and clean for manage all.
with this...I can resolve my problems here too, because under the Mediastation we are not able to open Qsampler, all the giga soundsbank is already preloaded by LSCP script.
think about :)
domenik
re Assignable I/O
Domenik,
I think I understand what you're saying, but doing it this way would not allow generic apps to used in the same manner. This would lock it into Qsampler only. Essentially, what I suggested should work with anything, be it Qsampler, Qsynth, Rosegarden, JAMin, etc. Sure, it would require loading the external app (hopefully automatically), but a feature such as this should function with anything that connects to jackd.
Perhaps Qsampler could be converted into a VST as well. ;)
Lexridge
Hi lexridge well...depend of
Hi lexridge
well...depend of the view point..I'm a older Logic audio user, where there the sampler is integrated and also is some more SEQ this sampler features are integrated on the system, because more easy to manage and save the whole session.
Perhaps Qsampler under VST can be interesting too, for much others windows application, but then to much setups to do, untill one sound for each track will be used:
Create track - select midi track- select mode: VST- load qsampler Vst-create Instrument-Load GIGA file-setup Midi CH-setup audio Out....and then again manage this all under qtractor...big work!
IF all is integrated under qtractor:
Create track-select midi track-select instruments mode: Linuxsampler-Load giga file-set midi CH-done!
Unlimited midi Tracks under the total simple Qtractor control and with the same Mixer interface, I think is much easy.
Anyway..I will leave Rui to choose the best and simple way....maybe copy the qsampler instrument loader code to the qtactor Instrument mode, is more simple and fast.
I will now enjoy Qtractor 0.1.1 and the new Qranger automatic Import styles that Rui made for me!!
One Qsampler per track
Perhaps Qsampler under VST can be interesting too, for much others windows application, but then to much setups to do, untill one sound for each track will be used:
I think we're stuck with one sound per track regardless, as Qtractor can only support one MIDI channel per track. Nothing lost, nothing gained. The real advantage of Qtractor as a VST would be simply for an auto-connection to a particular track. Sure, you would have to have multiple Qsampler-VSTs loaded into different tracks for different sounds, and I'm not really sure what kind of system overhead Qsampler/LinuxSampler needs. I assume regardless of how many Qsampler sessions are started, only one LinuxSampler process would be used, but I could be WAY off here. ;)
Lexridge
Playhead
The latest CVS is really nice here. :)
Would it be possible to have a separate edit cursor from the play head please? Being able to arrange while Qtractor is playing would be very useful if possible.
Cheers
Re: Playhead
I'm sure you'll have to be a bit more specific.
The playhead is represented by the red vertical line and always points to the current playback position. OTOH, all editing operations (with the sole exception of the newest clip split command) take position based at the edit-head (left blue line) and, to a far lesser extent, the edit-tail (right blue line). Or so it has been thought to be like so :)
In any case, all your suggestions will be kindly noted, as I think this editing cursor model is somewhat (out)dated; yep, it comes from very early design, a couple of years already, and quite frankly, I only find it useful for setting loop points.
Please, take the chance to let your (hopefully better) thoughts be heard, known and, who knows, made real ;)
Cheers
--
rncbc aka Rui Nuno Capela
No worries, its your
No worries, its your creation :)
Re: No worries
I guess it's a question of being worried with my creation ;)
I really would like to know about suggestions on improving the editing and arrangement workflow. The way I tend to do it (or think that I'm doing) might be outrageously different and worst, counter-intuitive to someone's else. That's just because I do cook my own dogfood :D
Any idea you might share?
Cheers
--
rncbc aka Rui Nuno Capela
When your composing why
When your composing why would you want to press stop for anything? If the editing head and the play head is the same tool your forced to press stop when you want to slice.
Loosing any tools when you press play has been a pet hate about most sequencers for years.
Clip Splitting while playing composition
I for one, am not sure I understand the concept you are pitching here. If you are going to split a clip, you would certainly need to hear it in order to find the split point. It seems this would conflict greatly with playing back your composition while splitting clips.
Lexridge
Clip slicing while playing
Yep, the clip split command is in fact affected to the playhead as the split point, so that you will need a lot of luck if you use it while playback is rolling. But, as said, this is the only edit command in this situation. Have in mind that you can select, cut, copy, paste, drag, move and (re)place any region or regions while playback is rolling. I won't recommend you do that while recording is engaged, for some obvious reasons, however it is still possible nevertheless. All these select-drag-and-drop operations don't give a damn to the edit and playhead cursors; you can do it on the fly, even using the keyboard arrow keys. Ain't that something? :p
Have you tried this? This drag-et-al functionality is, IMHO, one of the biggest starring features in Qtractor editing workflow, which I think stands out from the rest. I do admit however I did not pay much attention to that rest anyway :)
Hope that helps.
--
rncbc aka Rui Nuno Capela
Add new comment