Skip to content

Record performance is only recording loop audio that is played?

japjjapj
in Help
Hello,

It seems "record performance" is only recording the loop audio that is played?
And not including whatever is happening on the mic input during the playback of the loops?

E.g. when I sing verse 1 on top of a loop that is being played (without recording that verse 1 text) then this verse 1 text will not be included in the "record performance" (atleast, that is the behaviour I am seeing.. am I doing something wrong?)
It looks like the record performance is only including the audio that was/is actually part of a loop that is being played?

I would have hoped/expected that "record performance" would contain the same audio that I am hearing on my headset during the whole performance recording. If this is not the case then I need something additional in order to record the "full performance"?

Comments

  • JackJack
    Hmm, if you have headphone monitoring on then it should record what you play at the time. I will have a look myself and get back to you. thanks for pointing this out.
  • JackJack
    Hi @japj, tested this with my setup and it's recording the input audio stream just fine when headphone monitoring is turned on. Are you using an audio interface and monitoring your audio directly from that? This would result in your input audio not being recorded. In theory, I could change things so the audio input is recorded even if headphone/input monitoring is turned off but this would be quite a big job. What does everyone else think about this? @dubbylabby , @nonchai , @ricksteruk?

    If you are using an audio interface then i'd suggest getting an external recording device such as the Zoom H4 and plugging it into your mixer or interface. This is how i've done it in the past.

    Hope that helps!
  • nonchainonchai
    edited May 2017
    <What does everyone else think about this? @nonchai >

    Not a bad idea imo - but only after all other desirable features are added. Maybe for the time being this need can be met by using GTL inside AUM ? dunno.

    BTW can't wait for the beta to arrive - really want to try out and begin using those MIDI pedal mapping features !

    But also think that the whole GUI method for muting loops etc needs thinking out. there's just too many "finger-clicks" required for many common actions in live performance or live on the hoof composition situations. Turning on/off mute, playback, overdub need to be ideally a one-click thing.

    Since its most likely that its the last created or "touched" loop that would require quick control over - maybe some temporary buttons that appear ONLY for the last or "selected" loop playing might work - in order not to clutter the screen too much with extra buttons. I DO understand and appreciate the need to be minimalist and avoid clutter. Frankly if Apple came out with a sensor/camera that could tell where exactly the finger was hovering over BEFORE touching the screen - and providing context-sensitive buttons for the nearest loop that would be ideal - but .... alas we're not there yet ! :)

    ( of course using a MIDI pedal board does away with this but i still would like quicker access and intuitive control when not using MIDI controllers )
  • dubbylabbydubbylabby
    I vote for simplicity. If the actual path signal let us build layer by layer songs and only requires the proper setup of headphones/monitor variable... just put these "switch" in the transport menu (with autohide) and midi binding for it (to allow remote control).
  • japjjapj
    @Jack I used an Apogee One (input Mic and output headset).
    Using Audiobus and route audio output to a seperate app for recording might be an option to prevent too much complexity in GTL implementation/button options.

    That would require the input (mic) from the Apogee One need to go as input to GTL, output (both played loops and current audio input) of GTL go to recording app, recording app output go to headset. That might result in the same problem as I currently already have?

    Or another route would be to:
    mic input go to recording app (in a seperate recording track) that is app output and goes as input to GTL
    GTL then should also be an input (the loop playing) for the recording app in a seperate track.
    So you would have 2 recording tracks: one is the original microphone input and the second is the loop/group playing from GTL.

    I hope this makes sense?
  • JackJack
    edited May 2017
    @japj, yep that all makes sense. I always think it's best to try and keep it as simple if possible, especially if you're looping live. At the moment, really the best way to record the audio input using the iPad is to turn on headphone monitoring in GTL and turn off direct monitoring on your Apogee One, if that's possible. You will need a decent iPad to run GTL at a low enough buffer size to reduce monitoring latency.

    I will look into permanently recording the input steam regardless of the monitoring state when recording. As @nonchai mentioned though, It may have to wait until we've added some of the other pending features first.
  • JackJack
    @nonchai wrote:
    <What does everyone else think about this? @nonchai >

    Not a bad idea imo - but only after all other desirable features are added. Maybe for the time being this need can be met by using GTL inside AUM ? dunno.

    BTW can't wait for the beta to arrive - really want to try out and begin using those MIDI pedal mapping features !

    But also think that the whole GUI method for muting loops etc needs thinking out. there's just too many "finger-clicks" required for many common actions in live performance or live on the hoof composition situations. Turning on/off mute, playback, overdub need to be ideally a one-click thing.

    Since its most likely that its the last created or "touched" loop that would require quick control over - maybe some temporary buttons that appear ONLY for the last or "selected" loop playing might work - in order not to clutter the screen too much with extra buttons. I DO understand and appreciate the need to be minimalist and avoid clutter. Frankly if Apple came out with a sensor/camera that could tell where exactly the finger was hovering over BEFORE touching the screen - and providing context-sensitive buttons for the nearest loop that would be ideal - but .... alas we're not there yet ! :)

    ( of course using a MIDI pedal board does away with this but i still would like quicker access and intuitive control when not using MIDI controllers )

    Thanks for your thoughts, I'll have a think about making 'mute' quicker to access. Maybe it's just a question of improving the mute gesture.
Sign In or Register to comment.

© Vanilla Keystone Theme 2024