> BTW I need to record XRS but Soundrecorder won't work, any > other rec tool you know of which could work with Cortex?
There don't seem to be many BeOS apps that do recording. You could try BamBam or SimpleRecord (used to be available from the Be FTP site). Maybe even Soundplay, using the "live input" mode, in combination with writing to a file. Have you tried using AudioAdapter included with Cortex to avoid any format mismatches?
I've been thinking more about the multitrack problem recently, and I think I've got some idea of how it should be done. Simplicity is key, both from the user's standpoint, and the development standpoint. Unless anyone else wants to help develop this thing, then it's going to be just me, and with a sequencer to develop as well, I can't let it get too out of hand.
It seems that the Media Kit is entirely modular. The mixer is replaceable, but more importantly, there's no need for "plug-ins", since the Media Kit has that built-in already (Media Add-ons). If a simple multitrack recording application were written (could even be something like a virtual ADAT machine) with an output node for each recorded channel, a mixdown could be done entirely in Cortex providing some more media add-ons were written (compressor, EQ, etc.).
To make the process smoother, the mixer could be replaced. The mixer would have "slots" above each channel; clicking one would allow you to add a media add-on into the signal path, by disconnecting the app from the mixer, re-connecting it to the add-on, and connecting the add-on back to the mixer. Double click or something to open the control panel for that add-on. The mixer would also provide aux sends and busses, but nothing else to keep it simple; all EQ-ing would be done via media add-ons inserted into the slots. You'd also be able to add a new channel strip with a selected input source. This would essentially provide an "alternative Cortex", since using the groups you could route audio just about anywhere, allowing multiple apps to record at the same time, etc.
Some problems still exist though. The biggest is automation. While I think it's possible to save the current mix setup to a file, I'm not sure if it's possible to do useful automation. Automating the volume, pan and aux faders should be easy via MIDI controllers, but automating the plug-ins would be harder. This may be a problem, but on the other hand, it's a lot more modular and BeOS-like. It's either this approach, or a monolithic application that handles everything internally, and only exposes a "stereo out" to the media kit. The upside of that would be that automation is handled seamlessly. I could probably write the latter reasonably quickly, though the former will require a bit more research into Media Kit programming before I can begin that. Any idea which would work out best?
--------
As for the sequencer, I'm thinking a single-window interface would be the best approach to use. The arrangement window could be switched to the grid editor with a single mouse click or keypress; probably a secondary click at the position you want to go to. It'll probably be possible to "tear out" the grid editor into its own window, in case you want to edit in a separate window. Since I have a dual-head setup, I'd like the option of making the window large enough to cover both screens, or being able to see the arrangement and the grid editors at the same time; I'll see what I can do about that.
I've ditched the "tape clipping" approach completely now; it's going to be freely editable. Select the snap size, grab a selection and move it anywhere. I'm not sure whether I'm going to display bars in the arrangement window as solid blocks, or display the note data zoomed out like Sequitur does. Computation time might be a concern with the latter; I'll look into it.
I'm not sure whether audio recording should be integrated into the sequencer or whether it should be a separate app. Now that the mixing is going to be handled by the Media Kit, the audio features would be very simple -- cut+paste editing, globally selectable input source, and a selectable output destination for each track, and that's all.
Oddly, the biggest problem to integrating audio is actually the undo feature. I'd imagine audio editing would be destructive in nature, to keep things simple, and because it's a linear view rather than based on tape clippings. Because of this, multiple undo stages might be a problem. However, multiple undo stages are definitely required for the MIDI side of the application. If the user made a change to some notes, deleted a section of audio, changed some more notes, then deleted another audio section, there would be a problem. Hitting undo couldn't undo the first audio deletion, which would "stall" the undo history -- it'd be impossible to undo any further back, including for MIDI data. Clearly that's a user interface disaster, so there has to be some solution to it. Perhaps non-destructive editing needs to be implemented, but I'd really rather avoid that.
Complications with audio makes me want to keep audio as a separate app, but I'm not sure if that's such a good idea. I suppose it keeps things a bit simpler, but maybe it's a bad idea in the long run.Of course, if anyone feels like developing a multitrack audio recording application (even a simple one like an ADAT with no editing), that'd pretty much decide it...
|