From kde-multimedia Tue Jun 12 15:44:07 2001 From: Marc Siegel Date: Tue, 12 Jun 2001 15:44:07 +0000 To: kde-multimedia Subject: Re: Kde-multimedia digest, Vol 1 #211 - 9 msgs X-MARC-Message: https://marc.info/?l=kde-multimedia&m=99236890210219 Hey, I see a problem here. Am I correct that this precludes recording two seperate tracks at the same time from two seperate sources? It should be possible to do that if you ever want multi-track recording to be useful. -Marc > > aRts currently uses no explicit selection of input sources, neither > > for midi nor for audio. Rather the current strategy is through the > > (Audio|Midi)Manager objects. This works like that: > > > > 1. you start recording (playing), describing what you do > > > > 2. there are predefined points where you can record data from (play > > data to),which the user can connect your application to through > > artscontrol > > > > 3. the next time your application records (plays) again, it will be > > connected to the same point again > > > > It might be that you might want to change something in there, but > > thats the way it works right now. > > This sounds to me like you're saying it's impossible to select an input > source with the aRts API and that the user would have to run artscontrol > to choose an input, right ? This isn't very nice for the user, as they > would probably prefer to just start the audio recording program, pick > an input (mic/line-in/cd/whatever) and press record. > > > * opening, reading, closing: > > > > Well, recording is still somewhat on the aRts TODO list, but here is an > > overview what works and what does not. > > > > A. recording with server-side objects > > > > Creating a Synth_AMAN_RECORD (which does that AudioManager thing), and > > connecting it to a Synth_CAPTURE_WAV is the simplest style of > > recording. It will create a wave file in /tmp/mcop-/... - I > > did hardcode that for now because of security considerations (what if > > you get an .arts file by mail that "records" some file which already > > exists and thus overwrites it? or creates a file which you - as > > stupid user - will never find again?). > > You say you hardcoded the location that is saved to - so how would I go > about working around this ? Saving in /tmp isn't very useful. My /tmp > is in RAM :) Also, I'll want to monitor the input with level meters, so > the user can see that their input is working. If the data is going > directly to a file behind my back, I won't be able to do that. > > > So... as conclusion I'd say, it would be great if you write that simple > > recording application (we really really need that), and fix things on > > the way. (/me currently always uses artsbuilder with .arts files to do > > recording, which is probably not the ideal thing). > > Sorry, I don't want to spend a lot of time learning about aRts internals > and fixing stuff, I just want to write very simple audio recording app. > > If aRts doesn't support recording properly yet, that's ok, I'll just > drop the idea. > > Rik > > _______________________________________________ Kde-multimedia mailing list Kde-multimedia@master.kde.org http://master.kde.org/mailman/listinfo/kde-multimedia