takev

Hello everyone, So I finally have a screenshot to show you; for the new layout window. input and output assignment are already working, they have a circle shape because you can only assign one of them per channel. Cheers, Â Â Take

Hello everyone again, So I've been thinking a lot about how to implement it. It's going to be a lot of work, because I have to design a new GUI element for this. It will be a table that shows the channel number and names on the left side on the y-axis. The input numbers/names, output numbers/names and file numbers shown on the x-axis. Both of these headers are always visible and scrollable (the normal cocoa table only shows the top header). In the matrix are cells that you can turn on and off, to link a channel to an input, an output and a file. I will first replace the current layout with this new GUI element before I will work on the multi-polyphonic file support. But as the new user interface suggest that it will be possible to assign more than one input per channel I will implement summing. Take

hello Phil, I've heard from customers that the Boom Recorder works fine on the Intel based macs. I do not currently own an Intel based mac, but Boom Recorder has been compiled as a universal application and has always had big- and little-endian conversions for both architectures. it is very difficult for me to recommend either system, they should both be fast enough to handle 64 channels of audio (my old ibook G4 handles that), 1 GB of memory is also enough for Boom Recorder as it currently uses only 400 MB. Somewhere in the future you will be able to choose how much memory Boom Recorder is using, depending on the length of the ring buffer and the number of channels. As for interfaces I recommend using a firewire interface (not USB), some people like the MOTU Traveler, as it is about as large as a notebook and can be fed using DC-power or even via the firewire interface. Also the best harddrives would be external firewire drives, but the internal harddisk of a notebook is fast enough for most uses. Why firewire not USB? USB trickers a lot of interupts which the CPU needs to service, leaving less time for Boom Recorder, firewire can do a lot on its own. Also firewire has an isochronus mode, where a devices reserves a garantied bandwidth on the firewire bus, making sure it will never lose a sample and arrive in time. However, for most people this above does not apply to them, as 8 channels of audio can be handled with any equipment. To give you an example there are a couple of people using Boom Recorder for 8 channel recording with a iBook G3. However future version of Boom Recorder may need just a little bit more CPU power as more features are added, such as summing channels and multi-polyphonic file support. Take

I can finally enter this discussion. I've been following it because of the how to set the gain on the device, I've been very curious what people use in front of Boom Recorder as it can not realistically set gain for you (only a handful of audio interfaces have a programmable gain). QuickTime recording has been there so long that I am actually thinking of removing this feature. I've never been completely happy with it as it is uses a lot of CPU time. But I had to use the QuickTime API to create these files as the documentation didn't explain what the format was of high resolution multi channel .mov files. Don't worry, I will replace it with something better, it is possible to create stub QuickTime .mov files that point to the original .wav files for its audio data. So BR will then create both, so you can import the .mov files into final cut pro, and than later use the .wav files in your audio edit application. I guess you only have to search and replace .mov with .wav in the EDS that is output by Final Cut Pro. However next thing on the list... multi-polylphonic files. Cheers, Take

Hello everyone, I made a lot of changes in the core of this version, which is why I updated the major version number. I moved the timecode decoder to a separate file, in case I want to use it for an other project. I also changed the ring buffer handler so that It is more simpler, this also caused the ring buffer to keep a pre-record buffer even during playback. I also fixed the ring buffer view for this state (pre-record buffer + playback) and fixed the glitches in this view as well, it shouldn't be flickering anymore. I also added new timecode sources, as many people have been asking for time-of-day. I tried to be as accurate as possible, time-of-day is converted to timecode with microseconds accuracy (although the time-of-day is not that accurate), and use the sample rate of the audio interface as the clock. I'll wait a couple of days before ripping up Boom Recorder for the multi-file/multi-volume changes incase there are some bugs in version 6 that need to be fixed. Cheers, Take Vos

Hello Jeff, That is very useful information, I don't want to do anything that is counter intuitive against current ways of doing things. I guess then this would still be a normal table with checkboxes, or a couple of tables next to each other. It probably going to be hell making a standard cocoa table do what I want. Cheers, Take

Hello Philip, I didn't know that the clock of the Traveler is inaccurate. But I think it has a word clock input as well, if you have an accurate clock you could make the Traveler conform to it. Hello Jeff, Yes, the feature list is indeed getting complex, I will just have to do one at a time like I've been doing now. I've been thinking on how the user interface for the multiple file structure would be. I am thinking of one huge window, which will show the channels (maybe I will call it the bus now) as lines. Lines for the inputs, outputs and files will intersect the lines of the bus. You will be able to click the intersection to make or break a link, shown as a thick dot. Basically this will look like a schematic like they have in those manuals of pro audio equipment. Cheers, Take

- I'll see what I can do about the large window, maybe a seperate window you can open up, with this information. - Last take total time, is currently the time right under the transport buttons after the take (but includes pre-record time) - PPM with VU metering, current meetering does peek-and-hold (like PPM) and RMS over a couple of tents of seconds. RMS is positioned in such a way that RMS equals peak when using a sinus signal. I think that basically makes them a PPM and VU meter - Overload alert tone, how long and at wich frequency should this tone be? and where does that have to come out of, out of the monitoring output for that channel? - Programmable keypads and MIDI controll surface will apear in the future. - User controllable pre record time is currently in the preferences panel, but it has a maximum. - Offspeed playback is very difficult using the current architecture which was designed to be used for recording only, playback is really just a hack, which was actually quite difficult to accomplisch. I will also be adding generators which will include test-tones, timecode signal, click track and stereo playback (of a relativly short sound clip), I could handle offspeed playback in these generators. A generator would be a virtual input that you can assign to a channel, using monitoring you can assign to which outputs these have to be send. However the generator would have a very short time interval to do its work, so I am not certain that it would handle every generator I would think of, especially the timecode generator is quite difficult. Cheers, Take

Hello Philip, Yes, but No. You could create a aggregate device containing both the Traveler and the build-in audio and let Boom Recorder record from the aggregate device, but I don't think it can synchronize the sample clock between the Traveler and Boom Recorder and thus you will hear ticks in the audio. I have no plans yet to add a separate I/O cycle for doing timecode on. But there is maybe a solution that will work for you. Boom Recorder is able to jam against timecode at the start of the session and will freewheel the timecode against the sample speed of the Traveler (the internal computer clock is not accurate enough, and, this was easier to program). So you can feed Boom Recorder a timecode at the beginning of the day and during shooting reuse the audio input for normal audio, you can also jam between takes if you are worrying about drift. A customer was talking about making a switch that switched between timecode and the normal audio signal. I hope this helps, Take

Hello Jeff, I hope I wont make a broken promise with this. But I am confident that I will make this update as a lot of people have been asking for mirror recording and separate stereo mix recording. But lets first get Boom Recorder 6 out for release. Take

Hi Jeff, I will post it to r.a.m.p.s. myself, after I get some feedback from this group first. Take

Hello everyone, I am planning on releasing Boom Recorder version 6 this weekend, after doing some test to see if everything works as expected and seem to be stable using my system. The new version will include a couple of new time sources, including time-of-day, which a lot of people seem to be waiting for (weird how such a request come from multiple customers at the same time). An other feature was created by cleaning up some of the ring buffer code, Boom Recorder will now keep the pre record buffer, even during playback. This cleanup also solves some issues with the recording indicator, which sometimes was flickering off and on during recording, which does not instill confidence in the operators of Boom Recorder. (The flickering is only cosmetic, the files are recorded correctly) But this is not actually why I am writing this message. I want to mention that I have figured out a way to generically handle recording to multiple files. This will make it possible to: record a mirror copy on an other disk, create a stereo mix alongside the isolated mono tracks, or create any combination of polyphonic or mono files you can think of. an extra window or tab in the main screen will be added: - a "number of destinations" fields. - a table: for each destination you can choose a folder. - a "number of files" field. - a table: * from left to right are the channels. * from top to bottom are the files. * each cell in this matrix of channels and files will contain a checkbox. * next to each file a destination selection field. - buttons that are sort of wizards or presets that will create predefined combinations like: * make a mono file for each channel and mirror them across all destinations. * make polyphonic file with all channels and mirror them across all destinations. * make a mono file for each channel on one destination and a stereo file for the last two channels on an other destination. The following will be removed from the user interface: - mono or polyphonic (all the files are polyphonic, some just happen to contain 1 channel) - the arm buttons on the left of the meters will be replaced by the channel number. - the folder selection button in the setup window All of this will make Boom Recorder much more simpler internally as there are less corner cases, for example I now have separate code-paths for handling multi-mono or polyphonic files. I also will work on making the writing of the audio files more friendly for mutable metadata, as I am busy changing the file writing engine anyway, this change would create a fixed length header of 128 kByte which can be overwritten with new metadata without moving the audio data. This metadata friendly change would also make it possible to rescue BWF files after a crash of Boom Recorder or the system during recording, this probably would make the live-event registration people even more happy. Finally this change will remove some of the 64 channel limits in Boom Recorder, everyone needs more than 64 channels ;-) although this limit is still there for memory usage reasons, Jeff was already complaining about the long start up time :-P Some of you may think that if I am working on this, should I not work on mixing channels as well, and I reasoned: No. Mixing belongs in the channel layout, wouldn't it be great to mix using a MIDI control service? Ah, but then you would be complaining about the monitoring latency. But mixing would someday be added I think. I love to hear some of your suggestions around this new multi-file, multi-folder idea, before I commit on working on it. Cheers, Take Vos

Hello Ron, Thanks for letting me know that it is working for you. Cheers, Take

Hi, So what is the feeling for 32 bit float, which seem to be the native internal processing format of a couple of audio programs (some are doing 64 bit float), including Boom Recorder. If these programs are internally using floats isn't it better to keep the audio files in the same format? As floats are an exponential/logarithmic format is has more dynamic range than integers and are more accurate in filter processing (it certainly is easier to program these filters). An other advantage is that floats don't clip when processing samples through effect filters that amplifies the signal, most filters will handle sample values beyond -1.0 and 1.0. I've seen the same thing happening with high resolution image processing for film frames, that now process and store pixels in floating point. Cheers, Take

Hello Jeff, Since version 5.9 Boom Recorder supports 64 channels. During startup it will allocate a ring buffer twice as large as versions before this. As this ring buffer is locked in memory, OS X will first need to evict memory that was already in use in some kind of fashion. This eviction can take a long time as often the disk is involved with all this work. There are two ways for me to solve this: - A max channel control in the preferences panel, where you configure how much ring buffer will be allocated. This is pretty easy ot program, but it requires the user to restart Boom Recorder, there is also confusion about why there is a nr channels control in the layout panel. - Make the nr channels control in the layout panel change the ring buffer allocations. This is much more difficult to program but it would be more of the Apple way. Cheers, Take

Hello everyone, I changed the ballistics of the RMS/VU meter, it is now a little less twisty. I also added 32 float recording to BWF files, I have no idea how many edit programs will handle this, but 32 bit floating point is the format in which Boom Recorder receives the audio data from Core Audio. And a couple of other small changes. Cheers, Take

Hi, I've released a new version of Boom Recorder now. This one has the history in a separate window which doesn't do anything extra, except you can make the window larger. An other thing that has been changed it that I have turned off file-caching when writing or reading the BWF file in an effort to make recording of a lot of mono tracks more smooth. A customer had some problems recording 48 tracks and this seems to help the most, although using a firewire drive instead of an internal SATA drive helps even more.

No version 5.10 ;-), maybe tomorrow, maybe somewhere later this week. I am also planning some other things, plus I need a day off. Take

I've just put the history in a different window in my development version. It has not yet been released though, so you will have to wait a little bit. Cheers, Take

Thank you for the comment about the website, I am pretty happy with it, took me a week to get it like this. I will be adding more content to this, like examples of different setups; such as sound cart for feature films to 48 channel sound trucks. It would be nice to receive some information about how people are using Boom Recorder and pictures would be really nice. I am thinking of putting the history in a separate window that would be larger as well. Here you could then change the metadata and export this data to a csv file and also load csv files from previous versions. The csv files would have a fixed format though. Removing the history from the main window would leave me space to add the multiple file output user interface there. Would there be interest in MS decoding for monitoring such a thing, possibly recording both M+S and R+L. Or doesn't anyone use such a method of recording anymore. Are there edit programs that decodes MS? Cheers, Take

Boom Recorder currently writes out a .csv file together with the audio, this at least shows which recordings have been done, however changing a metadata after a recording can not be done yet with Boom Recorder. Also I guess I need to do something about the csv files when you can modify the metadata.

You can drag and drop BWF audio files which you recorded before (and maybe even from other equipment) in the history table. But only polyphonic files play back polyphonic. It will not yet join all the mono files when you drop one in. I've been thinking about using the history table as one you can modify such that the metadata in the audio file changes. This is more of a long term project and will only work with files recorded with Boom Recorder. This is a long term project as the audio files need to be written in such a way that there is extra room in the header for the changes in metadata, otherwise you would have to rewrite the complete file.

Are there any wishes for Boom Recorder? Sometimes things can be easily added, and it is the little things that will help the most people. Currently on the list that are a lot of work, so will not appear in short order: - Multiple copies of files to be created in parallel - MIDI Control - MIDI Timecode Cheers, Take

Hello everyone, I would like to spend this opportunity to tell you about the new version of Boom Recorder. This new version of Boom Recorder now handles 64 channels, instead of the previous 32 channels. Although most people doing feature film work would probably not need 64 channels, it seems to be that for recording concerts this is quite useful. This change did come at a cost, instead of using only 200 MB it now uses around 400 MB of memory. I know that many people here already have a lot of memory in their computer, so I hope this is not a problem. Cheers, Take Vos

Hello Jeff, Thank you for inviting me. I will try and keep up and pitch in when there are questions about Boom Recorder. Regards, Take Vos