[nama] Re: Considering a change to basic track settings
- From: Rusty Perez <rustys.lists@xxxxxxxxx>
- To: raf <rmouneyres@xxxxxxxxx>
- Date: Thu, 26 Dec 2013 13:23:40 -0800
Yes Raph, I am one of those who was, and am, confused by the recdef status.
It's probably a miner myracle that I was able to actually able to get
my Christmas music recorded because, I was flying by the seat of my
pants some of the time. :-)
Nama is AWESOM, but will be better as things are easier to understand. :-)
Thanks Joel for your HARD work!
Rusty
On 12/26/13, raf <rmouneyres@xxxxxxxxx> wrote:
> Hello,
>
> the discussion had started between Joel and me, because i said to him that
> it was confusing for me to see a (REC) state on a track when it was not
> actually recording, because of the rec_defeat option.
>
> So Rusty, you understand it the good way. Being as close as what's done on
> tape machine makes perfect sense.
> I also want the commands to be understandable by everyone, even the nama
> beginners, and you can count me in ;)
>
> Dealing with several ecasound engines is an different subject. The need
> comes from a live use were some tracks being in MON state, must absolutely
> never be disconnected. With the current version of nama, they are
> disconnected when you say "stop"... because you want to stop the song. But
> when you play live, you still want the mic to be opened when is song is not
> rolling. so you'd separate what has to be live, and what can be stopped.
>
> Raphaël Mouneyres
> 06 89 85 58 81
>
> Le 26 déc. 2013 à 17:51, Rusty Perez a écrit :
>
>> Hi namites! I hope everyone had a good Christmas!
>>
>> To the foregoing,
>> I would like to suggest, or at least afirm, the idea of keeping
>> vocabulary and behavior as close as possible to actual analog
>> recording machines.
>> This will confuse things more, but as I undertand it, a track atribute
>> of "rec" is analogous to arming a track on an actually recording
>> machine. When I used to record to tape, you would arm the track to
>> record to it, and you'd better unarm or disarm so you don't record
>> over your track.
>> And, there are really two layers of complexity here because in an
>> analog studio, you have a fixer with mutes faders, gain, pan ETC.
>> And you have the recorder which has arm, and monitor and off settings.
>> Anyway, I don't know if this has confused the issue even more, but, it
>> seems to me that this speaks to the issue of multiple engines, one to
>> act as the "mixer" and one to act as the recorder to save to and play
>> from disk?
>> Or, am I way off bass? :-)
>>
>> Rustym
>>
>> On 12/26/13, Raphaël Mouneyres <rmouneyres@xxxxxxxxx> wrote:
>>> Hello,
>>>
>>> I have another vocabulary proposition :
>>>
>>> r-m (currently REC status) >> REC
>>> -pm (currently MON status) >> PLAY
>>> --m (currently REC status with rec_defeat attribute set) >> MON
>>>
>>> REC means recording with monitoring activated
>>> PLAY means playing a file (it is what it is) with monitoring activated
>>> MON means monitoring the signal (it is what it is) without doing
>>> anything
>>> else
>>>
>>> then a mute control can come on top of all these three modes to shut
>>> the monitoring without disturbing the recording or actual playing of a
>>> file.
>>>
>>> woudl it make sense to everyone ?
>>>
>>> Raphaël
>>>
>>> 2013/12/24, Joel Roth <joelz@xxxxxxxxx>:
>>>> This issue goes back to the basic model of Ecasound,
>>>> a stream-processing engine that may not be dynamically
>>>> reconfigured.
>>>>
>>>> It also relates to having an "eager" mode, in which Nama
>>>> attempts to keep the engine running with instruments
>>>> constantly connected to monitors. And it relates to recent
>>>> discussions off-list about serving the audio mixing/routing
>>>> needs of a live band by running multiple engines, one for
>>>> permanent connections, others for writing files and
>>>> streaming prerecorded backing material.
>>>>
>>>> With this choice now we have two possible ways to disguise
>>>> Ecasound's limitations compared to a console with patch
>>>> cables. One is elegant: partitioning the audio processing
>>>> work among permanent and transient audio networks realized
>>>> by multiple Ecasound processes.
>>>>
>>>> The other technique is crude and simple: wrapping a
>>>> configuration change with fades and restarting the engine,
>>>> as we do when seeking.
>>>>
>>>> So, how would Nama work eagerly, more like a real desk?
>>>> For each track, we might like to be able to do all of the
>>>> following independently.
>>>>
>>>> Proposed commands/behaviors:
>>>>
>>>> 1. mon
>>>>
>>>> Monitor this track, i.e. connect its input and outputs
>>>>
>>>> 2. unmon
>>>>
>>>> Unmonitor this track, i.e. disable live monitoring
>>>>
>>>> 3. rec
>>>>
>>>> Prepare to record this track, writing a WAV file at the next
>>>> START command. Automatically clear any play order for the
>>>> track.
>>>>
>>>> 4. norec
>>>>
>>>> Clear a record order for this track.
>>>>
>>>> 5. play, enqueue
>>>>
>>>> Prepare a WAV file to play on this track at the next START
>>>> command. Automatically clear any rec order.
>>>>
>>>> 6. noplay
>>>>
>>>> Cancel a WAV file set to play at next START.
>>>>
>>>> Looks like we now have three separate attributes:
>>>> rec/play/mon, sort of like file permissions.
>>>>
>>>> These combinations can be allowed:
>>>>
>>>> r-- record WAV file
>>>> r-m record WAV file and monitor track output
>>>> -pm play WAV file and monitor track output # no live input
>>>> --m monitor track output
>>>> --- not connected at all
>>>>
>>>> If we use 'mute' instead of disconnecting
>>>> monitoring outputs, that leaves us:
>>>>
>>>> r-m (currently REC status)
>>>> -pm (currently MON status)
>>>> --m (currently REC status with rec_defeat attribute set)
>>>>
>>>> But we will have to separate these routes into two groups:
>>>> 1. Live monitoring routes (eager: streaming right now, normal: on
>>>> start)
>>>> 2. Rec and play routes (stream after START issued)
>>>>
>>>> The track's live source will have to be muted or
>>>> disconnected when a WAV file is played.
>>>>
>>>> Cheers,
>>>>
>>>> Joel
>>>>
>>>> --
>>>>
>>>>
>>>> nama> add bass
>>>>
>>>> Create an unconnected track
>>>>
>>>> nama> mon ??
>>>>
>>>> The signal from track input should immediately pass through
>>>> to the output.
>>>>
>>>> nama> rec
>>>>
>>>> Prepare to begin recording this track when the START button
>>>> is pressed. The new recording setup is generated, but is
>>>> not loaded.
>>>>
>>>> The engine continues to run.
>>>>
>>>> nama> un_mon
>>>>
>>>> This reverses the effect of the 'mon' command, creating a
>>>> new configuration without the current track's audio route.
>>>> The engine restarts.
>>>>
>>>> The record setup is regenerated, and omits the monitoring route.
>>>>
>>>> nama> add drums; source 2; mon
>>>>
>>>> Add the drums track with monitoring route and reconfigure.
>>>>
>>>> nama> rec
>>>>
>>>> No change to running engine.
>>>>
>>>> Regenerate the recording setup, preparing
>>>> to record this track as well.
>>>>
>>>> nama> add synth; import_audio... ; enqueue
>>>>
>>>> No change to running engine.
>>>>
>>>> Add the synth track, regenerate the recording setup to
>>>> include playing the imported audio file when the START
>>>> button is pressed.
>>>>
>>>> nama> start
>>>>
>>>> Disconnect and reconnect, running the record/play setup
>>>>
>>>> Cheers,
>>>>
>>>> Joel Roth
>>>>
>>>>
>>>
>>>
>
>
Other related posts:
