You are here

QTractor Wish List

Hi rncbc,
Here is the never ending list of ideas for QTractor that we talked about. None of these are completely my own, but borrowed from another DAW, which I beleive is the best DAW available under the Win32 enviroment. If you choose to impliment any of this, I would help you in every way possible, be it graphics design, building GUIs with the QT designer, whatever.

Here goes.........

OBJECT EDITING
I will try to explain how this should work, and it should mostly function the same be it audio or MIDI.

Unlike general track editing, picture the wav data itself on the timeline is not really the data itself. It is simply a non-destructive representation of it (pointers to the wav data). This OBJECT can be manipulated just as if it were actually wav data, but really is only a set of pointers to the actual data. The OBJECT can easily be split into pieces, with each piece having it's own independent properties, such as EQ, Reverb, Volumn, Pan, etc. (right click on the OBJECT, select Properties and a window (Object Editor or OE) should open with said parameters available for that single OBJECT)

Each track should be able to contain unlimited OBJECTS.

Each OBJECT should also support Linux plugins (whatever format you choose to implement).

Each indivual OBJECT can also be altkey dragged to another track, or shift-altkey drag copied to another track. Then, those new OBJECT properties can be manipulated seperatly of the original OBJECT as well, as if the original wav data was copied, but still using the original wav data, all in real time (hence the non-destructive-ness of it all).

In example, I have an OBJECT representing wav data, I drag a copy of the OBJECT to track two. Then, I do a pitch change, while maintaining tempo. Non of the original data is harmed in any way, but I've just created a harmony track on track two. No additional HDD space is used for wav data. The OBJECT pointers representing the pitch/tempo change and wav data are saved within the project data.

I hope I am making sense here. This is really a revolutionary way to edit audio. You might also not want to use the term OJBECT, as it could be copyrighted, but I doubt it.

TRACK SECTION (AUDIO)
- A track/wav editor: This can either be internal or external, but it must communicate with the track being edited in such a way to avoid having to save and reload, which generally means realigning the track in the timeline. This editor would be destructive only.

- Having to define a range before splitting a track is a minor pain. How about this method, align the cursor line to where you want the split, press the "t" key, and voila, the track is cut into two OBJECTS. Very neat, quick and effective.

-Rubber Band (or envelope) editing: This should work for both volume and pan, and be track wide. This will also affect any pan/vol settings in the Object Editor. Two different colour envelope lines to make it clear on the track timeline. Should also be able to hide these from the left side of the track (track number section. I don't know what you call that). As far as the effect on the OE (Object Editor), the volume distances would be maintained. ie, you have two Objects on a track, one with volume set to 60%, the other 80%. The volume envelope would keep them both the same distance apart until approaching 0 or 100%, but the OE levels would remain constant among the other objects on that track. The 60% Object would disappear first, followed by the 80% Object. Doing the opposite, the 80% Object would peak out at 100% followed by the 60% finally reaching 100%.

MIXER SECTION
- Built in basic effects: This is arguable, as many people prefer to use plugins for this, but a built in, and bypassable, 3 or 4 band (with sweep on each) is a must. A decent reverb is also expected in most DAW systems. Compression and Limiting would be nice to, all should be replacable with plugins if a user chooses to do so. All this should also be available on the Master Bus outputs.

- Mixer Snapshots with quick retrieve buttons. 8 should be plenty.

- Master Mono/Stereo switch

- Phase reversal switch (could be a track option instead)

- Master Compressor/Limitor on Main outs, or bypassable with user plugins.

- All knobs (pan, eq, reverb, etc) should be easily reset (centered) with a double click.

- At leaset 8 AUX sends and returns. The returns should have the same functionality as a standard audio track.

MIDI SUPPORT
- Does Qtractor support JACK MIDI? I've not seen many apps that do, and there may not be an advantage to it. What do you think?

- External Controllers: The cheaper ones should be supported first, for obvious reasons. Also should contain a "Learn" function.

- Continous Controller support as well for internal parameters such as pan, eq, etc.

- Advanced quantization or midi tracks or ranges.

METRONOME
- Audio metronome with user selectable samples and user selectable output point. I personally like to set the metronome to the center speaker, which I don't normally use while recording.

- Tempo Maps

KEYBOARD COMMANDS:
- HOME: Return to song beginning.
- Numeric Keys 0-9: Position Locators.
- m Key: Brings up Mixer
....more one this later.

This is enough for now. Wow, what a ton of stuff. Sorry about that. I like to be fairly verbose in my explainations, and I wanted to discuss advanced features before you reach the point of not backup up to make changes, if you decide to impliment any of this.

This is simply a list of my own suggestions, that I think will make QTractor the ultimate Linux DAW system.

What do you think?

Lexridge

Forums: 
rncbc's picture

Thanks Lexridge,

The above wishlist is highly welcome, and you know what? there are many of those wishes already granted OOTB :) I'll try to give you some comments on each of the major topics. Please, feel free to correct or make things a bit clearer on your part.

  • Object editing

    I guess most of editing in qtractor follows the non-linear, non-destructive model way as you suggest. The data that is pictured in the time line, in the form of clips, are parametric pointer references to audio or MIDI data files. When you change any of those segments, you're actually changing the clip parameters, not the underneath data file contents. You can have any number of clips that point to the same data file, also referring to the same or different locations or regions.

    Each track should be able to contain unlimited OBJECTS - Tracks can have any number of clips. The clips can even overlap each other (no auto-crossfades yet:)

    Each OBJECT should also support Linux plugins - Plugins are inserted at the track which a clip (aka object) belongs to. So there's no support for dedicated clip plugins, but only for tracks and buses. However, clip plugins might be an interesting feature, nevertheless.

    Each indivual OBJECT can also be altkey dragged to another track, or shift-altkey drag copied to another track - Each clip can be selected, dragged, dropped, moved, resized, cutted, copied, pasted, deleted, and all these operations have full undo/redo support as you might expect on a modern non-destructive editor. You can drag and move the selected regions either with the mouse or the keyboard (arrow keys). One additional clip property, which has been recently implemented, was time-stretching, very experimental though. Pitch-shifting is not currently available, you'll have to live with some track wide plugin for just that, sorry.

  • Track section (audio)

    A track/wav editor - To be honest, an audio sample editor is not very high placed in my TODO list :) but it's not forgoten either. I believe that is a perfect example sub-project for have it out-source, don't you think?

    Splitting a track - Splitting clips is indeed a minor pain. There's no single operation to split a clip at a given location. You can always select, cut and paste as workarounds :) The split operation is however very easy to get implemented. Noted.

    Rubber Band (or envelope) editing - What you call rubber-band editing is here assumed to be mapped as envelope automation of control parameters, or whatever we agree to call it. It's in the major plan, yes. The way I'm planning it is having any track control parameter, and that includes any plugin control parameter too, to be the subjects of dynamic envelop curves. That curves will show up on the track timeline and editable and recorded as usual. I guess this will happen sometime in the new year ;)

  • Mixer section

    Built in basic effects - I confess that built-in effects are not in the horizon. At least until this moment :) As you said, you can almost do anything with the available LADSPA plugins. However, yet again, if someone ever volunteers with some high quality (SSE2 optimized) DSP code for those standard effects, I'll be all for it :P

    Mixer Snapshots with quick retrieve buttons. 8 should be plenty - That's an good idea. What about named presets, similar with what you already have on plugins?

    Master Mono/Stereo switch - Right. But is this really strictly necessary? Unless you give a very good reason, I'm failing to put this one any higher from the bottom of the list ;)

    Phase reversal switch (could be a track option instead) - Any pointers on what this actually means? Is it turning upside-down the signal, positive being negative and vice-versa (ie. 180º phase-shift) ? In what situations could that be an option? I'm ignorant but I'm all ears :)

    Master Compressor/Limitor on Main outs, or bypassable with user plugins - Yes, plugins seems to be the way. And if you're thinking about mastering, you can always have JAMin plugged on the master outputs and bounced back.

    All knobs (pan, eq, reverb, etc) should be easily reset (centered) with a double click - Chalked. Just one middle-button click away, not a right-button double-click.

    At leaset 8 AUX sends and returns - This is also in the TODO list, but I'm thinking on a special pseudo-plugin that exposes track send outputs and return inputs as JACK audio ports, which will let you do whatever you want with the signal externally and then inject the result back in qtractor track output bus for mix-down. Does it seem reasonable?

  • MIDI support

    Does Qtractor support JACK MIDI? No, not yet. ALSA sequencer only.

    External Controllers. Currently, only MMC is supported for the most transport controls (rew, play, stop, ffwd, rec) and track switches (rec, mute, solo). Continuous controls (MIDI CC#s) are certainly a must have feature and is thought to be integrated when the envelop/automation batch gets it's due.

    Advanced quantization or midi tracks or ranges - Don't know whether it's advanced enough for you, but the MIDI clip editor already has this special batch tools that you can apply to selected MIDI events: quantize, transpose, normalize, randomize and resize. What's still lacking is something that I also care about which is a swing- or groove-quantize tool and also still in the TODO list.

  • Audio metronome
    This has been the subject for its own topic here. As there said, it will get its due implementation whenever out-of-session audio file preview/audition gets to the top of the backlog.

    Tempo Maps. This is certainly a current major design shortcoming. There's no support for tempo nor key signature map, and that will last for quite a while, I'm afraid.

  • Keyboard commands
    The Home key already does the track-view to reset position at the beginning of session. It does not affect the play-head, that's true. What about Shift+Home for just that?

    Regarding Numeric Keys 0-9: that will have it's right place when location markers gets real, which are also in the mighty TODO list.

    A Key: Brings up Mixer is indeed a very good thought. Will try to remember that next time I deal some code from the deck :)

....more one this later.
Keep'em coming :))

Cheers
--
rncbc aka Rui Nuno Capela

rncbc,
* Object editing

I guess most of editing in qtractor follows the non-linear, non-destructive model way as you suggest........

Each track should be able to contain unlimited OBJECTS. Tracks can have any number of clips. The clips can even overlap each other (no auto-crossfades yet:)

Ah, you touched on a point. This is something else a "Clip Editor" (CE, I was previously referring to this as Object Editor, OE) could have within it. One tab would be the functions I discussed earlier (eq, vol, pan, plugins) while another could be the types of available crossfades, and allow for dragable curves and distances per clip.

Each OBJECT should also support Linux plugins. Plugins are inserted at the track which a clip (aka object) belongs to. So there's no support for dedicated clip plugins, but only for tracks and buses. However, clip plugins might be an interesting feature, nevertheless.

This would certainly be a very powerful feature. :)

Each clip can be selected, dragged, dropped, moved, resized, cutted, copied, pasted, deleted, and all these operations have full undo/redo support as you might expect on a modern non-destructive editor. You can drag and move the selected regions either with the mouse or the keyboard (arrow keys). One additional clip property, which has been recently implemented, was time-stretching, very experimental though. Pitch-shifting is not currently available, you'll have to live with some track wide plugin for just that, sorry.

The LADSPA plugins I've seen for pitch shifting and temp correction have not been all that impressive, unfortunately. We'll get there eventually, no doubt.

A track/wav editor. To be honest, an audio sample editor is not very high placed in my TODO list :) but it's not forgoten either. I believe that is a perfect example sub-project for have it out-source, don't you think?

It would not have to be all that complicated as far as features. Basic destructive editing features such as cut/copy/paste would most likely be enough to satisfy most. Eventually sample rate conversion could be handy as well. However, Audacity does a fine job of this as is, it is just not integrated. Not really a big deal ATM.

Splitting a track. Splitting clips is indeed a minor pain. There's no single operation to split a clip at a given location. You can always select, cut and paste as workarounds :) The split operation is however very easy to get implemented. Noted.

Cool!

What you call rubber-band editing is here assumed to be mapped as envelope automation of control parameters, or whatever we agree to call it. It's in the major plan, yes. The way I'm planning it is having any track control parameter, and that includes any plugin control parameter too, to be the subjects of dynamic envelop curves. That curves will show up on the track timeline and editable and recorded as usual. I guess this will happen sometime in the new year ;)

This sounds great too!

Built in basic effects. I confess that built-in effects are not in the horizon. At least until this moment :) As you said, you can almost do anything with the available LADSPA plugins. However, yet again, if someone ever volunteers with some high quality (SSE2 optimized) DSP code for those standard effects, I'll be all for it :P

I'll see what I can come up with regarding this. Something else that is a really nice feature of Samp, when you double click on any of the four EQ knobs, it brings up a 4 parametric EQ. This works on each of the four EQ bands, and allows one to have a 4 band parametric on each of the 4 separate EQ knobs. Not that I've every used it on all four bands, but I'll bet someone has. ;) Very powerful stuff.

Mixer Snapshots with quick retrieve buttons. 8 should be plenty. That's an good idea. What about named presets, similar with what you already have on plugins?

This would work fine I suppose. It would need to be set up in such a manner that one could quickly A/B/C/etc between snapshots via a single mouse click, while the mix is playing.

Master Mono/Stereo switch. Right. But is this really strictly necessary? Unless you give a very good reason, I'm failing to put this one any higher from the bottom of the list ;)

Actually there is a very good reason for this. Switching to MONO on the fly is a very easy way to check for phase problems. Having to center all the pan controls could be a bit of a pain.

Phase reversal switch (could be a track option instead). Any pointers on what this actually means? Is it turning upside-down the signal, positive being negative and vice-versa (ie. 180º phase-shift) ? In what situations could that be an option? I'm ignorant but I'm all ears :)

Yes, you are correct in your understanding. This is really for microphone use. Especially drums. It is very handy for controlling leakage from other drums, and correcting for placement techniques. ie, some mics pointed up, others down. Here are a few links explaining some of this:

http://www.homerecordingconnection.com/forum.php?action=view_thread&id=7...
http://www.homerecordingconnection.com/news.php?action=view_story&id=133

Master Compressor/Limitor on Main outs, or bypassable with user plugins.
Yes, plugins seems to be the way. And if you're thinking about mastering, you can always have JAMin plugged on the master outputs and bounced back.

Yes, I kinda was thinking about Mastering, but the Jamin method should work fine.

All knobs (pan, eq, reverb, etc) should be easily reset (centered) with a double click.
Chalked. Just one middle-button click away, not a right-button double-click.

That will work fine :)

At leaset 8 AUX sends and returns.
This is also in the TODO list, but I'm thinking on a special pseudo-plugin that exposes track send outputs and return inputs as JACK audio ports, which will let you do whatever you want with the signal externally and then inject the result back in qtractor track output bus for mix-down. Does it seem reasonable?

This should work very well. Nice idea!

* MIDI support
Does Qtractor support JACK MIDI? No, not yet. ALSA sequencer only.

I'm not even sure this is necessary. I only brought it up because a few nights ago, qtractor was the topic of discussion on the #LAD irc channel, and someone was asking if qtractor supported it. After that, I started searching for Linux apps that supported it, and came up with none....at least none of the more popular apps support it. It was mentioned it was required for sample accurate sync. I wouldn't think this should be the case if everything is following the JACK master clock anyway. I'm still a bit unclear on all of this however.

External Controllers. Currently, only MMC is supported for the most transport controls (rew, play, stop, ffwd, rec) and track switches (rec, mute, solo). Continuous controls (MIDI CC#s) are certainly a must have feature and is thought to be integrated when the envelop/automation batch gets it's due.

Understood. The Behringer BCF2000 and BCR2000 with automated (flying) faders is a popular unit, mostly due to it's low cost. It is MIDI or USB connected. I will try mine out with qtractor (I think it supports MMC) in the next few days.

Advanced quantization of midi tracks or ranges - Don't know whether it's advanced enough for you, but the MIDI clip editor already has this special batch tools that you can apply to selected MIDI events: quantize, transpose, normalize, randomize and resize. What's still lacking is something that I also care about which is a swing- or groove-quantize tool and also still in the TODO list.

I guess I wasn't being very fair here, as honestly, I have spent very little time on the MIDI section of qtractor. I will play with it some more.

* Audio metronome
This has been the subject for its own topic here. As there said, it will get its due implementation whenever out-of-session audio file preview/audition gets to the top of the backlog.

Yea, I had originally posted in that topic regarding this. I just thought I would bring it up on this list to keep some type of organization about it.

Tempo Maps. This is certainly a current major design shortcoming. There's no support for tempo nor key signature map, and that will last for quite a while, I'm afraid.

I admit this is a very complex thing to implement, and even harder to make it work correctly. Perhaps if the MIDI engine code were separated from the main tree, it would be easier to get third party help on this. Admittedly, I have not looked through much of your code. I'm not much on C++ anyway, but experience with C and other languages makes it easier for me to understand what is going on, in most cases.

* Keyboard commands
The Home key already does the track-view to reset position at the beginning of session. It does not affect the play-head, that's true. What about Shift+Home for just that?

That would be okay, but what about reversing that idea? Use Shift+Home to reset the track view, and Home to return the playback head.
EDIT: Actually, don't change anything. The backspace key is perfectly fine. I guess I hadn't realized the backspace key function. What about a Shift+Cursor left and right for a scrubbing function? The speed of the scrub could be set somewhere else, or use Shift+Cursor for slow scrub, and Ctrl+Cursor for faster scrubbing. What do you think?

Regarding Numeric Keys 0-9: that will have it's right place when location markers gets real, which are also in the mighty TODO list.

Yea, I guess that is like putting the cart in front of the horse. ;)

A Key: Brings up Mixer is indeed a very good thought. Will try to remember that next time I deal some code from the deck :)

Thanks! :)

Keep'em coming :))

I certainly will, and thanks for your time on this. :)

Lexridge

I've decided that really the best way to come up with sound ideas (pun intended) was to actually quite playing around, and actually start recording a full project with Qtractor. So, I have started one.

The first thing I ran into was wanting to edit the clip length of my first track. The way it is now, I have to change the start and end parameters from within the Clip - Qtractor window (F4). Not a pleasant experience, and difficult to be accurate. What would be REALLY nice is this: Where you have the little squares on the top ends of the clip box, add the same thing to the bottom or center of the clip box as well, except the bottom/center little boxes would resize the clip box itself, as you drag the mouse. This would make editing out sections exceptionally simple, and quick. Actually, the little boxes wouldn't really be necessary, just allow the clip box to resize by placing the mouse on either of roughly center of either end, mouse pointer turns into a <--> and allows the resize. Whichever would be the easiest to code I guess. Either would work equally well. Also, I think you could entirely drop the Offset parameter with this type of clip box resizing....unless I am misunderstanding the use of the Offset.

Also, put a padlock icon in the center of the clip box. This would allow locking the clip into place to avoid accidentally moving the clip box on an erratic mouse movement. It could also function to lock the resizing of the clip, and fade-in/out as well. Perhaps a preference setting for what gets locked.

BTW, the latest CVS build is working great!

Thanks,
Lexridge

rncbc's picture

Clip resizing. There's currently another obvious way to resize a clip without setting it explicitly from the clip properties dialog: just select and cut the region at the end of the clip. In case you've missed, there are three selection modes: clip, range and rectangular (Edit/Select Mode menu) and for doing this resize workaround you're best with the rectangular mode. This will select only that clip areas or regions that fall under the rubber-band rectangle. Then you cut (or delete) the selected region. Simple, eh?

Ok seriously, I'm considering your suggestion in doing the resizing by dragging the clip edges with the mouse. I'm also considering to have the clip time-stretched in addition (shift-drag?), that is, changing the audio clip time-stretch factor in proportion to the clip size change. What you think?

Clip locking seems to be a nice idea too. Another one of yours that get noted ;)

Cheers.
--
rncbc aka Rui Nuno Capela

I apparently missed this. I assumed there should be an easier way to do this, but never did discover it. Thanks for the tip. Perhaps I can contribute on this project by writing some documentation for you.

Ok seriously, I'm considering your suggestion in doing the resizing by dragging the clip edges with the mouse. I'm also considering to have the clip time-stretched in addition (shift-drag?), that is, changing the audio clip time-stretch factor in proportion to the clip size change. What you think?

I think this would be a fine addition. The Shift+Drag is the same way it is done within Samplitude, so I'm all for it. :)
EDIT: Wow, you are quick! I see you've already added the dragable clip resizing feature in 0.0.9.791. Woohoo!!

Clip locking seems to be a nice idea too. Another one of yours that get noted ;)
Wonderful! :)

Thanks again Rui!
Lexridge

rncbc's picture

Just to let you know that resizing by dragging the clip edges is already a reality as of last cvs commit (qtractor 0.0.9.792+).

Cheers
--
rncbc aka Rui Nuno Capela

Wow! You are the man, Rui. Very fast work indeed. :)

EDIT: This version seems to have a problem with drawing the waveform.

Thanks!
Lexridge

rncbc's picture

Hmm. Regarding audio waveform drawing, I've added one closing point to the polygon routine... but what is actually the problem?
--
rncbc aka Rui Nuno Capela

I am getting a blank/empty clip box....absolutely no waveform whatsoever. The file plays, just no waveform.
EDIT: Well, here's a strange one....when I run it as root, I have the waveform displays. The issue must be on my end.
EDIT: Fixed. The problem was I had compiled it as root (opps, I don't normally do this) and was running it as my regular user from the build directory.

However, when dragging the clip box from the left side to the right, I would expect the audio clip to get cropped in the same manner as it does from the right side, dragging left. This is not the case. Instead, the data gets shifted to the right.

Lexridge

rncbc's picture

it looks like there was in deed a problem by this side too; fixed as almost a regression, in cvs (qtractor 0.0.9.793+).

please update and try whether the bad drawing symptoms are still around.

byee
--
rncbc aka Rui Nuno Capela

Repost regarding new clip resizing function: When dragging the clip box from the left side to the right, I would expect the audio clip to get cropped in the same manner as it does from the right side, dragging left. This is not the case. Instead, the data gets shifted to the right.

Lockup condition: When I Add Track/Audio then click on the far right button to get the Buses dialog, then select anything besides Duplex, I can then click Update and Close. So far, so good. But when I then click Okay on the Track dialog, the whole program locks up. Please check if you can reproduce this.

Perhaps I'm doing something wrong here. Basically, I was just trying to configure qtractor for 8 mono inputs so I could record some live drums from my M-Audio Delta 1010.

Thanks,
Lexridge

rncbc's picture

The clip resizing one was fixed, now behaving as you might expect. I hope :) (qtractor 0.0.9.795+).

The second one, regarding the lockup, needs some more time to look at. I'll try to get to it later, maybe tomorrow.

Seeya.
--
rncbc aka Rui Nuno Capela

Ah, this is pure beauty! Works like a charm now. Again, you are THE MAN! You're working some late hours too, as I assume you are in/near Italy somewhere. I'm on US eastern time here in WV.

Q: How does one turn off the "snap-to-grid" on this? I desire some pretty fine editing and the grid snap gets in the way.

Thanks man!
Lexridge

rncbc's picture

Thanks for the praise :)

I'm from Portugal, the most western country in Europe and having the same time as in the UK. I guess there's a 5 hour lag to WV (West Virginia?).

How does one turn off the "snap-to-grid" on this?Just set the snap setting to "None" on that dropdown box at the main toolbar, right after the tempo (bpm) box; also on the session properties dialog (File/Properties...); the snap settings usually defaults to "Beat/4" meaning a quarter note.

Unfortunately I can't hunt that lockup bug atm. Will look at it later, tonight.

Cheers.
--
rncbc aka Rui Nuno Capela

I'm from Portugal, the most western country in Europe and having the same time as in the UK. I guess there's a 5 hour lag to WV (West Virginia?).

Yes, West Virginia is correct.

Just set the snap setting to "None" on that dropdown box at the main toolbar, right after the tempo (bpm) box; also on the session properties dialog (File/Properties...); the snap settings usually defaults to "Beat/4" meaning a quarter note.

Ah, that is where it is. I guess I couldn't see the forest for the trees. ;) Thanks!

Unfortunately I can't hunt that lockup bug atm. Will look at it later, tonight.

Sounds good. :)

Lexridge

rncbc's picture

Just added the SHIFT mode to clip resizing a few minutes ago (cvs; qtractor 0.0.9.799+) which, as promised, also applies time-stretching in reciprocal proportion to the size change.

Due to that lockup bug's been stomped earlier today, this thread can now put to rest. Or so I believe, you tell me :)

thankyaa
--
rncbc aka Rui Nuno Capela

Just downloaded this version. Looking forward to trying the Shift mode Time Stretching. :)
EDIT: Just tried out the Shift mode Time Stretching. I hate to say it, but qtractor segfaults and disappears from X entirely. :(

Regarding the lockup bug, please see my previous comment.

thanks! :)
Lexridge

rncbc's picture

Just tried out the Shift mode Time Stretching. I hate to say it, but qtractor segfaults and disappears from X entirely
LOL. Looks like we're opening yet another can of bugs :) Will try and test it more thoroughly and see whether I can catch that tonight.

EDIT: I'm struggling to reproduce this one, yet again. On my systems it doesn't crash (even on windows:D). However, probably there sure is something hideous. Are the segfaults happening all the time you change the time-stretching of a clip, or is it random?

In either case, please try to catch the offending code spot by catching a backtrace with gdb. If surely helps in fixing this one.

byee
--
rncbc aka Rui Nuno Capela

I have only compiled today's release on my work computer (I'm here for about another 30 minutes before heading home, then to my computer shop for about an hour).

Are the segfaults happening all the time you change the time-stretching of a clip, or is it random?
It happens every time.

I will compile it on my home computer as soon as I get there and let you know what happens. Both this machine here at work, and my home machine both are running FC6, but are vastly different as far as hardware.

What is the best options/syntax for gdb. I have not used the gnu debugger before.

EDIT: Strange, gdb seems to cause qtractor to exit. It attaches, then it causes qtractor to exit. I'm using #gdb -pid=PID.

Lexridge.

rncbc's picture

I think the easiest way is about having a core dump telling all its post-mortem secrets...

  1. Rebuild it all from scratch, with:
      ./configure --enable-debug && make
    
  2. Enable core dumps in a shell session:
      ulimit -c unlimited
    
  3. From the same shell comman line, run the program until it crashes badly. You'll see something like this in the output when it happens:
      Segmentation fault (core dumped)
    
  4. Locate the dumped core file. Depending on your environmental settings it might be just named core or something like core.1234 (1234 is the process-id number of the crashing program) located on the last directory the program was current.
  5. Load the core dump file into gdb
      gdb ./qtractor /path/to/core
    

    at the gdb prompt just enter:

      gdb> bt
    

    or

      gdb> thread apply all bt
    

    and send the whole output to me.

HTH
--
rncbc aka Rui Nuno Capela

Okay, got it built here at the house, and low and behold, it works terrifically! Nice job....great feature!

Now, I will have to run the debug stuff on the machine at work tomorrow and find out what's going on with that machine.

Lexridge

rncbc's picture

In the Key: Brings up Mixer department, now you have it: there's new keyboard shortcuts for bringing up/down the Connections (F8) and the mighty Mixer (F9) tool windows.

Enjoy
--
rncbc aka Rui Nuno Capela

P.S. Still trying to reproduce the lockup bug, to no avail. Can you give the precise steps again to make it happen?

Great news! I had actually have been messing around a bit with your .ui files in QT Designer, and have added some custom keys myself. I'm happy it's in the official source tree now. :)

I'm not sure I can describe how to achieve this lock up condition any better than I did. I have built qtractor on three separate systems, and I can make all three of them lock up in the same manner.

Add an Audio Track then click on the far right button (Manage buses) to get to the Buses dialog.
Next, select anything besides Duplex (either Input or Output).
Next, click Update and Close.
Then click Okay on the Track dialog. Qtractor is now locked tight.

I need to go to a friends house and set up his WIFI this evening. When I get back in, I will try to better describe the events. Perhaps if there is a way to turn on debugging, that might help.

--EDIT--:
I think I may have a handle on this. I have not been renaming the Bus when doing this little operation. I have been leaving it as defaulted to "Master". When I rename it to say, "Input 01", it does not lock up the program, and everything is smooth sailing. It works as it should, in other words. It looks to me like the code does not like the duplicate name. Perhaps a quick check on the name is in order here, and a forceful dialog asking one to rename the Bus should pop up before allowing the window to close....or......just create a non-duplicate name based on the selection (Input.1, Output.2, Duplex.12, etc)

I'm guessing you have not been able to reproduce this because you have been giving the Bus a new name, unlike me.

BTW, I have not been able to find a .ui file where you are creating your Mixer GUI. Are you not using QT4 Designer for the Mixer GUI?

Also, the Mixer hotkey is dynamite! Thank you! However, I have changed mine to the "M" key. It's just more obvious to me. A personal preference, if you will, and what I am used to from working for years with Samplitude.

I have been trying to get my head into your code. As I said previously, I am not a C++ programmer, YET, but I learn very quickly. In a few months, I may even be able to submit code to you. I believe this Qtractor program may make a C++ programmer out of me yet. :) Thank you for sparking my interest, Rui.
--END EDIT--

Lexridge

rncbc's picture

Master bus lockup - Yes! You're hit the spot about the lockup issue. Now I can reproduce it anytime too. It sure needs all a users imagination to find subtle bugs like this one. Thanks for the patience. Now its a question of time to get that one squashed! :)

Mixer GUI - don't look for a .ui file because the mixer widgetry is build up in code without help of Qtdesigner. And what was you looking for exactly?

Keyboard shortcuts - As you might know then, keyboard shortcuts are currently hardwired in the .ui files. Maybe it's a good idea to have this configurable to user preferences (maybe might not the right word:), and just maybe it's yet another task with very high out-sourcing potential :)

I have been trying to get my head into your code. - Hope you don't get stuck on it :D My C++ coding style is somewhat old-school and still somewhat reminiscent from my early C and Windows 3 SDK experience, almost from 16 years ago. I'm sure it is no big fancy top-notch esoteric C++ style, so that it will be easier for you to cope.

Thanks again.
--
rncbc aka Rui Nuno Capela

rncbc's picture

Another one bites the dust ;)

CVS HEAD (qtractor 0.0.9.798+)
--
rncbc aka Rui Nuno Capela

The lockup is indeed now gone. However, if I continue leaving the default name (Master), the mixer channel strip gets all messed up. The strip lacks a fader, and is generally scrambled. I of course know now not to do this, but nonetheless, the naming issue lays a bit deeper perhaps than meets the eye.

EDIT: When this happens, all the connections to JACK get broken as well.

Mixer GUI - don't look for a .ui file because the mixer widgetry is build up in code without help of Qtdesigner. And what was you looking for exactly?

Nothing in particular. I was actually wanting to see if I could change the fader handles to something a little larger and more like a real mixer. No biggie however....just wanting to play around mainly.

Lexridge

rncbc's picture

Argh. I fixed the lockup alright, but failed to tell you that changing Master mode to anything but Duplex is not a good thing to do. Guess I will disable it: Master buses will be always set to duplex mode. You can change the name, the number of channels or the auto-connect flag, but not the mode. We'll see if that's enough... :)

When you change the name, or anything else for that matter, of one particular bus, you will in deed recreate the corresponding infrastrutural ports from scratch (either jack for audio or alsa-seq for MIDI), so that connections to the previous port instances will be lost and the new ones are not reissued. It's just the way it is, sorry ;)

Byee
--
rncbc aka Rui Nuno Capela

Argh. I fixed the lockup alright, but failed to tell you that changing Master mode to anything but Duplex is not a good thing to do. Guess I will disable it: Master buses will be always set to duplex mode. You can change the name, the number of channels or the auto-connect flag, but not the mode. We'll see if that's enough... :)

Okay, fair enough, but now how do I add additional input channels? I assumed this was the way to do it. I would not need more that six or eight presently, but two certainly isn't enough.

Thanks,
Lexridge

rncbc's picture

How do I add additional input channels?
Just create new input-only buses.

If your intent is about recording from several inputs simultaneously, you'll have to create one bus for each input and then assign each bus to the target track on input.

Don't worry, this layout will be saved in the session file as well the corresponding connections, so that you don't need to do that all over again. You can even save the session while it has no recorded material as a template for future sessions, provided you manage with distinct file names.

Cheers.
--
rncbc aka Rui Nuno Capela

Okay, that seems to work okay. This is what I was trying to accomplish when running into the lockup bug.

Thanks,
Lexridge

Pages

Add new comment