You are here

Monitoring while recording on a muted track

Hi,

I'm not completly shure, but according to this routing scheme it should be possible to record on a track that is muted while having monitoring of the same track activated. If i get this right, the input should be routed to the output of that track(due to activated monitoring) while the playback should not. What actually happens is, the input as well as the monitoring is muted while recording.

Is this a bug in the implementation or in the routing scheme? Or do i just misunderstand the routing scheme?

greetings

Forums: 
rncbc's picture

now that you ask :)

might there be a bug in the routing graphic ? not a bug per se, only that the routing diagram might not be quite accurate in that matter: in fact, "mute" is implemented such like "suspended from all processing" ... but wait, i don't quite get to reproduce what you report as evidence :/ recording actually works on muted tracks, either audio or midi and under monitor or not--so i guess things seems to be correct still on the diagram front.

care to elaborate on what is really wrong? maybe i'm missing something...

sorry if that mislead you before.
hth.
cheers

Right, maybe my description wasn't that accurate either :) Recording on an muted track isn't an issue. I just wondered why monitoring of a track was muted either despite the fact that the routing scheme says the oppsite (at least the signal path of the monitoring doesn't go through the mute symbol). It was a bit strange because monitoring worked fine although mute was activated until i hit the play button. So monitoring of a track is muted during playback(and playback with record activated). To me that felt a bit inconsistent.

rncbc's picture

oh no, monitor(ing) does NOT work on muted tracks when playback is rolling!

yep, i admit that's inconsistent with the evil block diagram :) but look that "bug" only applies to audio tracks; MIDI tracks are correct on both ways, real and diagrammatic :).

ok. that's a finding... alas, i must confess i fail to feel the urge to correct it anytime soon, if you know what i mean ;)

thanks anyway
cheers

rncbc's picture

it was only now that i realised this "bug" was dang easy to fix, hoping there aren't any nasty side-effects following suit ;)

so svn trunk r4123 aka. qtractor v0.6.3.17 has it hopefully fixed.

hth.
cheers

Thanks for your effort, also hoping it's not introducing nasty side-effects :) I will give it a try, a soon as my distro updates its package. At the moment, i switched to ardour, but their midi support is somewhat broken/unstable. Also they don't have a 'takes'-feature yet, as found in qtractor. At the moment i'am really undecided, which way to go. Qtractor in my opinion felt way more stable than ardour does(at least by counting the crashes i expirienced) and has a really responsive support :).

rncbc's picture

holy thanks.

before you leave, let me please ask about two tasks you might be possibly right and eligigle to fullfill, both dealing with loop recording / takes feature which, as you say, is a niche one you seem to master already.

1) starting from qtractor v0.6.3.23 svn trunk, there is going to be this experimental integration with punch in/out recording mode--youd be welcome to test and harness the new behavior, whih is kind of rough in the edges, buggy and still far from finished though.

2) what about making your precious experiences into the wiki?

no obligation whatsoever.
cheers

Which 'precious experiences' exactly do you mean? Those about the takes-feature? Sure, i can try to document it as far as i'm able to. Do i need a sourceforge account to edit the wiki? Do they support github-logins via oauth? For me the takes feature worked quite well. The only thing to complain about was the shortcut 'shift+t' which only worked, after at least choosing 'next take' once via the context menu. I wish qtractor had the fancy feature i saw in a video about logic or something, where it is possible to view all takes in parallel and then select the best parts of each take to combine them into a final version :)
I have allready tested some punch in/out recording but i'm not sure if you refering to something else. I'm using the qtractor package from my distro which is build from http://downloads.sourceforge.net/qtractor/qtractor-0.6.3.tar.gz, as far as i can see. Does this version already include the svn revision? Otherwise i have to create a custom build.

rncbc's picture

yes. you'll need a sourceforge.net handle, before i can add you to the board of wiki editors.

otoh. the new loop-punching/takes feature is only available in development svn trunk of course. you can grab the latest snapshots du jourfrom here

the new feature is about making the punch-in/out intersection with loop-recording/takes possible, meaning that a recording is not disengaged when the play-head reaches the punch-out point that is located within the looping range--it just goes on looping. the resuklting clip-takes do get cut at the punch-in/out points though. that's the new deal.

hth.
cheers

Ok, i just wrote a buildfile that builds a package directly from the svn using the latest revision available, so i can build and install new version easily. I was surprised, compared to ardour it really takes no time to build, nice.

So i checked out the described feature, but i'm not sure if i fully understand it. I made a loop selection, then made a punch in/out selection within this loopselection, armed the track and started recording. Hope thats what you meant? However, the result is, that only within the first cycle something gets recorded(like a normal punch in/out recording). After the playhead reaches the punchout marker it continous to playback the loop. Maybe i did something wrong? From your description the feature sounds really handy to me.

rncbc's picture

only within the first cycle something gets recorded(like a normal punch in/out recording). After the playhead reaches the punchout marker it continous to playback the loop.

yes that's what's supposed to happen: the play-head now continues over the loop, not stopping at the punch-out point anymore. however, on each loop turn-around a recording take is implied on each punch-in/out segment; isn't that what you get ?

ok, as said, the thing is still rough in the edges. that's why i count on you to pull up some strings there :) you might get some misalignment between each punch-in/out clip-take, but make sure the whole recording is integral without gaps for instance when you reset it (via Clip/Take/Reset).

seeya

[UPDATE:] an important fix has sneaked in svn trunk [r4139] aka. qtractor 0.6.3.24. please make sure you pull for a new build ;)

I checked out the latest revision, but it's still not working. Recoding is disabled after the playhead passes the punchout marker.

rncbc's picture

really? that's the previous behavior indeed (< v0.6.3.23)...

is any of the punch-in/out points inside the loop range? is loop-recording/takes actually enabled ? like its mode set to anything else but "None" ?

seeya

As i said, i choose a loop range by placing the editmarkers and clicking on the loopbutton. I then placed the editmarkers both inside inside the loopmarkers and clicked the punch in/out button. So at this point, there is a looprange and inside of it also a punchrange. But recording takes place only once and is getting disabled after it..

rncbc's picture

and, sorry to ask, are you sure you're running the latyest v0.6.3.24 fresh build ?

byee

Yep, help-window shows:

Qtractor - An Audio/MIDI multi-track sequencer

Version: 0.6.3.24
Build: Nov 1 2014 13:05:08
VeSTige header support enabled.

By the way, multiline code-tags support seems to be broken. It only wraps the first line inside a code tags excluding the following lines(at least in preview)

Sorry for the doublepost, just tried to edit my posting, to escape the code-tags i used, but oddly it created a seperate one. I just made myself a git clone of the svn repo so i can try to track down whats going on with my qtractor build.

I found out why it's not working. I wasn't aware that there is an option in the preferences dialog which sets a 'loop recording mode' (i think you were refering to that but i didn't get it). I think this is somehow related to the fact, that this feature isn't documented in the wiki yet and i found out about it by fiddling around :) . I used the takes feature in a way, that i set a looprange, turned on the loopbutton and started to record. When doing so, the recorded stuff was appended as one large clip (instead of overwriting the previously recorded stuff). When i first stumbled upon this, i was wondering, but then found out about the takes option in the context menu which turned that into a smaller clip, which size was controllable by different range options. Having set the 'loop recording mode' while making looped recordings makes much more sense. The behaviour of appending instead of overwriting while recording in a loop is a bit confusing (at least for me it was). But apart from that, it works great :)

Add new comment