takev

I am have finished coding 8.3.0, I am now updating the manual since a lot has changed. The last few days I have redesigned the ring buffer view and transport buttons so they look nice on a retina display. In the weekend I will have to do some test to see if what I did was kind of right. And here is a preview of the new buttons:

Yes, but in that same spirit, you also want to have the sample rates on the main display; and probably a whole host of other things. I have some ideas about showing information more information on the main window, not sure how. In the mean time I think the frame rate settings has a better place in the Time Preferences window. In case you are wondering, in the new version of Boom Recorder there are two different frame rate settings: - On-set frame rate - File frame rate I've heard of people having a 30 fps on set, but want a 24 fps in the sound logs, since they are editing at this frame rate.

Hi, here is more work in progress. Since the frame rate selection has been moved to the Time Preferences window, there was visual room to resize the tape counter and time code. I had to put it underneath the note because it visually looks much better than at the top. I spend hours figuring out this new layout that doesn't physically hurt your eyes. Hopefully my thunderbird->firewire cable arrives today so I can do some tests this evening on the new pull up/down system. Otherwise I am going to implement the custom frame rate settings.

Hi, I've been working hard on the new pull/up down system. Here is a screen shot for it. My solution is the whole truth and nothing but the truth. You specify all the sample rates you want and the real-world frame rate and Boom Recorder should be able to figure out how to timestamp the audio files and sound reports correctly, and show the correct timestamp on the main window. I've already finished coding it, but it requires very good testing before I release it. Which is going to be hard because I do not have access to a word and time code clock which can run at weird speeds. Also I need to change the documentation quite a bit to explain this.

The octo-pre has a button to select from 4 sample rates, I guess the audio interface should be set to the same sample rate. You can clock your audio interface to the octo-pre by selecting the ADAT input. If you have an external clock you either let both interfaces share the same word clock, or you clock the octo-pre and let the interface slave on the ADAT input. I myself have the octopre and a MOTU 828 MkII. But am just a software developer not a sound engineer.

Hello again everyone, Sometimes I am just steaming ahead, I released 3 different versions today. Yes three, because Boom Recorder 8.2.0 is just released. This is my first change toward better pull up / pull down. You can now enter any sample rate your audio interface supports. For most people that will not help much because most interface only handle a hand full of sample rates. However RME's FireFace 800, if I remember correctly, supports whole ranges of sample rates, including the exotic and very much needed 48048. Before you could not select 48048 in Boom Recorder, but now you will. When you enter a sample rate Boom Recorder will send this sample rate request to the audio interface, if it succeeds the sample rate will be set to it. If it fails (because the sample rate is out of range) then the sample rate reverts back to the previous setting. For the owners of the FireFace there will be some changes compared to how you used to record at 48048 with Boom Recorder. Since now Boom Recorder understands that the interface is really running at 48048, you no longer have to lie about the frame-rate. So the frame-rate must now be set to the actual real-world frame rate. This means your timecode on the screen, the timecode in the sound report and the timestamp in the audio file will all match, yippee! For everyone who doesn't own an audio interface with exotic sample-rates you will have to keep lying to Boom Recorder like you have done before. I hope I can change this soon. Cheers, Take

Hello everyone, I finally finished the new preferences architecture in Boom Recorder. Functionally this version is not different, but some of the preferences have moved between the tabs of the preferences window. I really wanted to finish this because I have some plans for changing how time and pull up / pull down works. Although I had the old and new preferences side by side for comparison and I have tested it carefully this is quite a big change. Be careful before going into production with this version, but I would love if you can try it out. Cheers, Take

Boom Recorder saves the audio file to disk when recording. But if the computer crashes during the recording, then the header of the audio file is not complete yet and you will not be able to use the file. Use BR File Fixer to rescue these files. It looks at the size of the file on disk, then checks some information in the header that was written and then corrects the header. You can find it at: http://www.vosgames.nl/downloads/

Something like this maybe? http://www.amazon.com/Sima-SMP-1C-Monopod/dp/B000165GJI Attach it to the side of the bag so the bottom is flush with it. Of course it takes too much time to extend and retract it.

file n : File class elements contained by channels. properties enabled (boolean) : File enabled for channel output n : Output class elements contained by channels. properties attenuation (real) : 0-254 dB attenuation, 255 mute input n : Input class elements contained by channels. properties attenuation (real) : 0-254 dB attenuation, 255 mute channel n : Channel class elements contains files, outputs, inputs; contained by application. properties name (text) : Channel name folder n : Folder class elements contained by application. properties path (text) : Folder path application n : Boom Recorder app elements contains folders, channels. properties state (text) : Current state project (text) : Current project scene (text) : Current scene slate (text) : Current slate take (text) : Current take roll (text) : Current roll note (text) : Current note timecode (text, r/o) : Current timecode counter (text, r/o) : Current tape counter frameRate (text) : Current frame rate bitDepth (integer) : Current bit depth preRecordTime (integer) : Current pre record time autoCommit (boolean) : increase performance of channel layout commands record v : Start recording record stop v : Stop recording or playback stop abort v : Abort recording abort play v : Start playback play

Hello everyone, I have released the latest Boom Recorder, version 8. This is the first time I will charge for an update to Boom Recorder and I will try to get it on Apple's App Store. It is not yet in the app store, but if you like you can now buy Boom Recorder 8 from my own website: http://www.vosgames.nl/ One last thing, version 8 will only work on OS X Lion. As I mentioned before the biggest changes are in the meter bridge, with vertical meters and maximum peak meter. Below follows a complete list of changes: - Adding AppleScript state property, which may be polled to show the current Boom Recorder state. - Boom Recorder is now build with xcode 4.1, which means that Boom Recorder will only run on OS X 10.7 (Lion) or higher. - Fixes depricated API calls. - Removed divide by zero error when loading foreign audio files. - Increased contrast of buttons in the patch-bay. - Click through enabled for transport buttons and patch bay. - Scroll wheel now functions in the patch-bay. - Maximum attenuation is for input/output mixer 114 dB, or infinity of course. This may reduce CPU time a little. - Renamed BoomRecorder to Boom Recorder, make sure you update your AppleScript applications. - Added Boom Recorder Lite and Boom Recorder Pro applications for Apple's App Store. - Renaming menu items in case of other names. - Removing Register menu item, and preferences panel for App Store and for value added reseller versions. - Fixed incident reporter to be able to take screenshots again (maybe it was only a problem when running inside the debugger). - Boom Recorder is now a 32 bit and 64 bit application. - Application will now be signed by Take Vos's developer key. - Vertical meters - Channel name on meters can be removed for more space. - Saving and loading of input and output patchbay has been fixed when using more than 128 channels. - Show maximum peak value in meters, click to reset. - Remembers which utility windows are open, and shows these as pushed buttons on the main window. - Enabled full screen mode on main window. - CoreAudio callback starts an release pool so that the "leaking" error message don't show up in the log file. Cheers, Take

Hello everyone, It seems that Boom Recorder 7.25.3 is working on Lion, although I haven't spent to much time working with it. Right now I am trying to finish Boom Recorder 8.0.0 and get it on the App Store. Boom Recorder 8.0.0 will only work on Lion; this is because I wanted to use some new APIs. Next to a lot of small changes, the biggest changes are in the meters: - Optional vertical meters - Optional names on the meter, so that there is more room when using a lot of channels. - Optional maximum peak meter, which only resets once you click in the meter (sort of like a clipping indicator). Cheers, Take

I do not know if Pyramix shows them (Protools does) but you can rename Boom Recorder's tracks with something more descriptive on the main window.

There are a few people who do record that many channels in a single poly file. Most often these are people doing concert recording and I think the files are used with pyramid. pyramid also can use the wav64 files that Boom Recorder can write out when the file size limit is set beyond than 4 GB. When you record 96 tracks such a file quickly grows larger than 4GB.

Hello, You may be able to rescue the audio in the file by reading it as raw data in some audio utilities. In those utilities you give it the length of the header it should skip, the amount of audio channels, the sample rate and the bit depth. Boom Recorder's header is always 32768 bytes long. An other way to fix it is using a hex editor and fill in the missing fields in the wav header, such as the file sizes. This is quite a bit more complicated.

The latest version for Tiger is 7.25.1 The newest version should work with Leopard on both 32 and 64 bit power pc and intel CPUs. And to handle 256 channels you need a giant screen as you see. There are some features available to programmers if I will drop the power pc and 32 bit intel, so at some point I will want to use that. 64 bit will also allow me to read files in a special way (using mmap system call) which could help me make Boom Recorder playback much better.

Hello there, I have just released 7.25.2 and 7.25.3, the first release addresses a problem with playback of many mono files. If you had issues where Boom Recorder would play the audio silently this may solve the problem. It is a quick fix that may not actually help, but I am hoping it will. There are also some fixes to small bugs which the new compiler found for me. The second release of course includes the fix in 7.25.2 as well, but also raises the maximum number of channels you can record to 256. It seems there are customers who think 128 channels are not enough, the change was easy enough so there we go. Both versions are compiled with a new compiler making it impossible to release them for Tiger. So these two versions only work for Leopard and Snow Leopard.

I am pleased :-) I still wonder why I am not in sync with the other recorders though.

No, that shouldn't be an issue, it will just delay the start of the recordig until it reaches 00.

This is indeed quite odd, my next question would basically be, what if you give two Boom Recorders the same timecode feed. I can imagine there be a small fixed offset between Boom Recorder and 744T when both slaving from one timecode, as both are interpreting the start of a frame differently. As a timecode signal has 80 subframes (close to 100), and it is two subframes in front, means that either Boom Recorder or the 744T stamps the frame in the wrong place. I checked my code and the sync-word (not a preamble, but a postamble) is behind the frame, the leading edge of the first data bit in the timecode is the start of the frame. I have not found anything in the standard about the exact position of the start of a frame, so everyone could interpret it slightly differently. Also to find the exact position of the leading edge of a data bit I needed extra programming to remember the position of each bit. I am not sure why in your case BR was so far off compared to the 744T, maybe it doesn't listen to its own timecode and thus follows an other path to retrieve the timecode.

According to the BBC standards I once read they want sync to within half a frame, so you should be good :-) I actually read back the mail, it was not 6 samples, it was 52 samples, which is around the same as those 2/100th of a difference in your case. He attributed this to latency in his rig (pro tools with 002R). Maybe I am using the wrong edge for the detection of the frame. Maybe I have to skip the preamble or something. I will do some calculations tomorrow.

I am also puzzled about the 2/100th of a difference. When you did that test, where you aggregating with an other device? To be exact did you Jam on an other device then that you compare the metronome on? The way Boom Recorder is designed if you use one interface, it should be accurate to within a sample. Unless the front edge of the LTC frame is not vertical enough and does not zero cross at the correct position. To be true, I think in the specification of LTC it asks for the timecode signal to be passed through a low pass filter to reduce high frequency interference. So it may be that the LTC signal is according to spec and the edge is very slanted, I haven't read anything in the specification where exactly on the edge a new frame starts, I just assumed it would be the zero cross. A long time ago someone else did a test in a sound studio and he got it accurate to 6 samples. 6 samples I can see happen because of a slanted edge. I think 2/100th of 30 fps is around 32 samples at 48000 Hz?

I was thinking, maybe the audio files Boom Recorder took are accidentally recorded at 44100? If you use an other audio application next to Boom Recorder it may change the sample rate. Boom Recorder does not change the sample rate by it self, and needs to be set every time Boom Recorder is started by user or when an other application took control of the sample rate. Boom Recorder will follow the sample rate correctly, so the audio files should be shown to be 44100. I do not know what Final Cut Pro does with audio files with sample rates different from the timeline. I think Final Cut Pro resamples to the correct sample rate, however although the sample rate is set to 44100, the MOTU actually is clocked to 48000, making FCP adjustments an error again. Ok, it is early in the morning, you may need to ignore my ramblings. Take

What is MOTU's clock source set to?

Are you saying that previous Boom Recorders didn't have this issue?