Greetings, Great idea Sasha. I'm in: - Computer used: Mini PPC 1.42 GHz - Operating system used: 10.4.6 - Sequencer used: Logic 7.2.1 - Soundcard used: MOTU 828Mk2 (Firewire 400) - Settings used (buffersize and samplerate): 256, 128, 64 and 32 with Sasha's click file (44.1/16 bit) - Resulting offsets in milliseconds and/or samples: 256 samples: 14.1 ms. 128 samples: 8.3 ms. 64 samples 5.4 ms. 32 samples 4.0 ms. Additional comments: - I had to measure samples and divide by 44.1 to get decimal accuracy; Logic otherwise only supplies rounded whole numbers for milliseconds; this seemed worthwhile to see what's happening between 64 and 32 samples, and even between 64 and 128. - I recently did MIDI recording delay tests on the above system, which showed that going through a Roland GI-20 guitar MIDI converter to an EXS instrument would, compared to a simultaneous analog signal, add an additional delay of 17-24 ms. As in the above, there was almost no difference between 32 and 64 samples. Since I only measured the recorded delay, my reasoning is that I'd have to add this MIDI delay to the above offset to get the latency I actually hear playing EXS MIDI through the GI-20 - ie., 256 samples - 14.1 + MIDI 24.4 = 38.5 ms 128 samples - 8.3 + MIDI 21.0 = 29.3 ms 64 samples - 5.4 + MIDI 17.8 = 23.2 ms 32 samples - 4.0 + MIDI 17.2 = 21.2 ms Steven Rowat

On Nov 17, 2006, at 12:37 PM, Steven Rowat wrote: > Greetings, > > Great idea Sasha. I'm in: > > - Computer used: Mini PPC 1.42 GHz > - Operating system used: 10.4.6 > - Sequencer used: Logic 7.2.1 > - Soundcard used: MOTU 828Mk2 (Firewire 400) > - Settings used (buffersize and samplerate): > 256, 128, 64 and 32 with Sasha's click file (44.1/16 bit) > - Resulting offsets in milliseconds and/or samples: > 256 samples: 14.1 ms. > 128 samples: 8.3 ms. > 64 samples 5.4 ms. > 32 samples 4.0 ms. So this interface has a baseline latency of 112 samples, or about 2.5 msec, about halfway between the Symphony and the MH. For those folks doing this stuff, it would be helpful (because I'm lazy and don't want to do it every time) to view the measured latency in samples, and subtract the buffer latency (twice the setting), to get the baseline latency of the hardware and driver. You can then calculate the baseline latency in msec by calculating (samples * 1000 / sample rate). Please also do measurements at 96k... --Dave

Greetings, Blair's data indicate that 96Khz doesn't always make a huge difference in the latency; whether it does appears to be device dependent (Digigram VX Pocket vs Tascam 1082), and Peter Ostrey asked about whether 24 bit matters vs. 16 bit, so I thought I'd add a few measurements on the MOTU828 to compare 16 to 24bit and 44.1 to 96khz. I only did 128 and 64 buffers, since this seems like the current 'state of the art'. - Computer used: Mini PPC 1.42 GHz - Operating system used: 10.4.6 - Sequencer used: Logic 7.2.1 - Soundcard used: MOTU 828Mk2 (Firewire 400) - Settings used (buffersize and samplerate): 128, 64 with Sascha's click file, each at: 44.1khz/16bit; 96/16; 44/24; 96/24 44.1/16, 128 samples buffer: 366 samples = 8.3 ms 44.1/24, 128 samples buffer: 366 samples = 8.3 ms 96/16, 128 samples buffer: 414 samples = 4.3 ms 96/24, 128 samples buffer: 414 samples = 4.3 ms 44.1/16, 64 samples buffer: 238 samples = 5.4 ms 44.1/24, 64 samples buffer: 238 samples = 5.4 ms 96/16, 64 samples buffer: 286 samples = 3.0 ms 96/24, 64 samples buffer: 286 samples = 3.0 ms I also checked if whether always having a 44.1/16 bit original 'click' in the bounce confounded at 96/24 or 44/24 by bouncing down a 96/24 bit click and using that as the original. I did this with three of the measurements, not shown above because the results were identical in all cases to using the 44/16 click. Concusion: at least on the MOTU 828mk2, a) 16 or 24 bit makes no difference in latency; b) 96 versus 44.1 sample rate makes a noticeable difference (reduction); c) this difference is not directly proportional to the sample rate. d) As was suggested by someone in an earlier post (which unfortunately no longer have to quote from, my apologies), this can be simplified by removing the sample buffer, to give a standard fixed "overhead" for this machine, which equals 110 samples for 44.1khz identically at 128 samples or at 64 samples. (356-256 = 110, or 238-128 also = 110), or 2.5 ms. e) HOWEVER, this overhead changes at 96khz to 158 samples = 1.6 ms. (414-256 = 158, or 286-128 = 158). So this 'fixed overhead' is also complex, because it appears to be *partially* affected by sample rate. But since at this point we're dealing with fractions of a millisecond I really think I need to get out more. ;-) Steven Rowat

On 11/18/06 12:30 PM, "Steven Rowat" <steven_rowat@sunshine.net> wrote: > Greetings, > > Blair's data indicate that 96Khz doesn't always make a huge > difference in the latency; whether it does appears to be device > dependent (Digigram VX Pocket vs Tascam 1082), and Peter Ostrey asked > about whether 24 bit matters vs. 16 bit, so I thought I'd add a few > measurements on the MOTU828 to compare 16 to 24bit and 44.1 to 96khz. > Steve Thanks for posting the 16 vs 24 bit figures. That is good to know. I agree with what you said about the device making more of a difference than the 96k sample rate ­ the figures for the Digigram card were interesting. However, on the Tascam FW-1802 my measurements showed about the same correlation most of us seem to be getting. At 96k it seems to be about half of the 44.1 figure for all the more recent cards. What these figures mean in term of usability is another issue, but I¹ve said my piece on that already :) Maybe I should post my Digigram results on the database. It would also be interesting to get some results from people with some other higher latency interfaces to get a better overall picture. Most folks seem to be using RME, MOTU, Metric Halo etc. and it¹s great to get info on these units. However, I am looking at buying 16 new interfaces for a computer lab soon ­ and I¹m not likely to be buying higher end gear for this lab, so information from people using some of the more affordable interfaces would also be welcome. Blair -- blairfisher@shaw.ca

On 11/18/06 12:30 PM, "Steven Rowat" <steven_rowat@sunshine.net> wrote: > > I only did 128 and 64 buffers, since this seems like the current > 'state of the art'._,___ This is a good point. As this database grows, I would suggest a few small changes: I guess the most important would be a suggestion that we limit the sample rates on the database to USABLE rates. For example, I was able to get the Digigram card to record at a 64 sample buffer, but would not consider it usable. Perhaps everybody is already doing this, but if you list a 32 sample buffer it should be safe to assume that you can use the card at this setting. Likewise, if your card works well at 128 and 64, maybe we should do as Steve did and not list the 256? I guess the other thing would be to try and standardize the computer naming, since the database is sorted that way. That¹s probably not really important, since what we are measuring here is mostly the interfaces, but we do have people using the same computer listed in different places because they called it ³Apple G5² or ³G5² One final thought ­ maybe it would be better to sort by sound card? Thanks for putting the effort into designing the database... Blair -- blairfisher@shaw.ca

More tests: - Computer used: Macbook 2.0 - Operating system used: OSX 10.8.4 - Sequencer used: LogicPro 7.2.3 - Soundcard used: Internal - Results: 44.1 kHz, 64 samples buffer: 763 samples = 16 ms - Notes: Won't test at any other settings as it's just clear that the internal hardware of the Macbook is as bad as it gets. For on-the-road virtual instrument only work it's sufficient though, and it's also working reliably at 64 samples, but you better forget about software audio monitoring. - Computer used: Macbook 2.0 - Operating system used: OSX 10.8.4 - Sequencer used: LogicPro 7.2.3 - Soundcard used: M-Audio FW410, latest driver revision - Results: 44.1 kHz, 256 samples buffer: 792 samples = 18 ms 44.1 kHz, 128 samples buffer: 531 samples = 12 ms 44.1 kHz, 64 samples buffer: 403 samples = 9.1 ms 44.1 kHz, 32 samples buffer: 339 samples = 7.7 ms 96 kHz, 256 samples buffer: 1035 samples = 10.8 ms 96 kHz, 128 samples buffer: 779 samples = 8.1 ms 96 kHz, 64 samples buffer: 650 samples = 6.8 ms 96 kHz, 32 samples buffer: 587 samples = 6.1 ms - Notes: Card runs really fine at 44.1/32, but crackles appear under not too high system loads, so I'm usually using 64 samples (almost no difference in CPU loads compared to 128 or 256). The rather small differences between 44.1 and 96 at low buffer sizes are certainly somewhat interesting. But if you were running 96k projects, you'd use another card anyways. - Computer used: Macbook 2.0 - Operating system used: OSX 10.8.4 - Sequencer used: LogicPro 7.2.3 - Soundcard used: Native Instruments Rig Kontrol 2 (USB), driver coming with Guitar Rig 2.2. - Results: 44.1 kHz, 256 samples buffer: 809 samples = 18.3 ms 44.1 kHz, 128 samples buffer: 553 samples = 12.5 ms 44.1 kHz, 64 samples buffer: 425 samples = 9.6 ms 44.1 kHz, 32 samples buffer: 377 samples = 8.5 ms 96 kHz, 256 samples buffer: 950 samples = 9.9 ms 96 kHz, 128 samples buffer: 687 samples = 7.2 ms 96 kHz, 64 samples buffer: 559 samples = 5.8 ms 96 kHz, 32 samples buffer: 495 samples = 5.2 ms - Notes: For a USB device, this is performing quite well. Also, NI seems to have gotten their driver act together fine, as the "CPU overhead when just idling" previous driver versions caused is gone. Again, it's not something I'd really use 96k or other higher samplerates with, but if you're picky about live playing latency, it might be worth a try if your computer can handle it. Under Logic, I can run it fine at 64 samples without crackles, but there's a certain CPU overhead compared to 128, so, if you wanted to mix with Rig Kontrol at all (probably not the best idea...) it might be a good idea to switch to 128 or even 256. Note to those of you using NI's Kore: It's using the same chip/driver, so the results will be identical. I'll add all my results to the database later on. Regards Sascha

--- In logic-users@yahoogroups.com, Blair Fisher <blairfisher@...> wrote: > > I guess the other thing would be to try and standardize the computer > naming, since the database is sorted that way. That¹s probably not really > important, since what we are measuring here is mostly the interfaces, but we > do have people using the same computer listed in different places because > they called it ³Apple G5² or ³G5² I agree. If we can decide on this, it's no trouble to go in and edit the field entries already there. Do we prefer "Apple G5" or "G5"? > > One final thought ­ maybe it would be better to sort by sound card? Maybe it would indeed, but have you tried exporting the database? This produces a text file, which can be imported into a program such as excel, in which you can do all sorts of re-arranging of the information. So, if you want to analyse by Soundcard, or buffer size, or user name, you can ... I am sure there are valid arguments for having the audio card as first field, or the computer type, or buffer size etc. At the end of the day, we have to settle for something for the first field, but I do see the real value of this information in being able to process it in ways that yahoo's database structure simply can't. > Thanks for putting the effort into designing the database... Jeremy, Orren and Sascha all had good ideas. After that, there was very little to it, not least of all because the framework that yahoo offers is so simple. kind regards Mark Cahill

Here are some results, I thought it would be interesting to compare the RME Fireface 800 and Multiface/Cardbus. I had to carry these tests out on a PC notebook, the Mac Book Pro doesn't accept the Multiface with Cardbus, I don't have a G4 Powerbook: - Computer used: Toshiba Pentium 4 2.8 HT 1.25 GB RAM - Operating system used: Windows XP SP2 - Sequencer used: Logic Platinum 5.5.1 - Results: Tested at 44,1kHz 24 bit RME Multiface I/O Buffer 128: 321 Samples, 7 ms I/O Buffer 64: 193 Samples, 4.4 ms RME Fireface 800 I/O Buffer 128: 396 Samples, 9 ms I/O Buffer 64: 268 Samples, 6 ms Tested at 96 kHz 24 bit RME Multiface I/O Buffer 128: 323 Samples, 3.4 ms I/O Buffer 64: 195 Samples, 2 ms RME Fireface 800 I/O Buffer 128: 397 Samples, 4.1 ms I/O Buffer 64: 268 Samples, 2.8 ms I had a lot of trouble getting the FF 800 to run at 96 kHz at all, it only played ball after re-starting logic several times, and kept sending reset requests. The multiface was a lot better behaved in this respect. There were no other FW devices attached. These results are purely for comparison. Personally, I usually work at higher buffer settings and rely on total mix or an external mixer for monitoring. I seriously doubt that this system would run well at 96 kHz with 64 or even 128 samples under any sort of reasonable studio load such as 20 + tracks already recorded, some already treated with plugins, along with some virtual instruments and samplers running, and then carrying out overdubs. kind regards Mark Cahill

On 19.11.2006, at 12:54, markdvc2002 wrote: > These results are purely for comparison. Personally, I usually work > at higher buffer settings and rely on total mix or an external > mixer for monitoring. That is an important point because the results of the test might be misleading if one interprets them as a measurement of the overall quality of an interface in the time domain. We measure overall latency with active software monitoring. Compared to "direct" monitoring that involves an additional run of the recording signal through the computer and Logic. The results do not tell how well an interface behaves if you don't use software monitoring. Like Mark I use also exclusively direct monitoring via Totalmix and my record delay in Logic is set to zero. In this case it counts how precisely the sound of the playback meets the sound of my own signal. When I re-record a Logic track via a cable between an output and an input of the Fireface 800 the difference is 0 or 1 sample. Normally both signals go to the headphones. That tells me that the playback and the recording signal reach my headphones at the same time. If there are timing errors after a take they can only be mine. Plugin delay compensation must be off for recording of course. Otherwise Logic waits for the slowest plugin, puts out the playback later and the recorded signal would be too late relative to the existing tracks. ___ Peter Ostry

> On 19.11.2006, at 12:54, markdvc2002 wrote: >> > These results are purely for comparison. Personally, I >> > usually work at higher buffer settings and rely on total >> > mix or an external mixer for monitoring. On 11/19/06 5:01 PM, "Peter Ostry" <po@ostry.com> wrote: > That is an important point because the results of the test might > be misleading if one interprets them as a measurement of the > overall quality of an interface in the time domain. We measure > overall latency with active software monitoring. Compared to > "direct" monitoring that involves an additional run of the > recording signal through the computer and Logic. The results do > not tell how well an interface behaves if you don't use > software monitoring. > Like Mark I use also exclusively direct monitoring via Totalmix > and my record delay in Logic is set to zero. In this case it > counts how precisely the sound of the playback meets the sound > of my own signal. When I re-record a Logic track via a cable > between an output and an input of the Fireface 800 the difference > is 0 or 1 sample. Normally both signals go to the headphones. > That tells me that the playback and the recording signal reach > my headphones at the same time. If there are timing errors after > a take they can only be mine. I think this is a really good point. I usually use a hardware mixer, so the latency issue is not something I have ever really thought about too much. I also have CueMix DSP available on the MOTU interfaces we use, so that is also an option. Even our little Tascam US-428 has a monitor mix function, so I am not usually dealing with software monitoring. It has been interesting seeing what the state of the art is for software monitoring, and I have been contributing to the database. However, I am always interested in hearing how people actually use the equipment, and how relevant the numbers really are in real world use. Seems like lots of people are adding those kinds of comments with their results, which makes it much more interesting for me that just looking at the numbers in the database. Peter: do you think that there might be better ways to measure the ³overall quality of an interface in the time domain² as you have put it? How about the test you describe ­ have you tried that on other interfaces, and does there seem to be any variation? I guess I should try that test as well.... Blair -- blairfisher@shaw.ca

On 20.11.2006, at 04:51, Blair Fisher wrote: > Peter: do you think that there might be better ways to measure > the “overall quality of an interface in the time domain” as you > have put it? How about the test you describe – The test is almost like John Pitcairn describes it on his website. He can certainly give better in-depth information than me. What I do is straight forward: Record a short bit of audio to get a region. In the sample editor make it all silent, zoom far in, take the pencil and draw a couple of spikes. Then connect a cable between an interface out and in. Record your spikes on a different track. Cut both regions shortly before a spike. Open the original and the recorded track and measure the samples from the start to the spike. > have you tried that > on other interfaces, and does there seem to be any variation? I > guess I should try that test as well.... I did that with all interfaces I had. A Delta Card, a Firewire 410 and now the Fireface. I do not remember the Delta but it was different with the FW410. I think I had a record delay around -250 samples but I am not sure. --- There is another issue where it is good to know about several latencies: yesterday I recorded a mic directly to Logic and simultaneously through an analog compressor to compare the sound. The compressor was inserted via Totalmix which means: Direct signal: Mic >> interface >> Logic Processed signal: Mic >> interface >> D/A convertion out >> Compressor >> A/D convertion in >> Logic. If I remember it right the difference was 72 samples for the two convertions. That is important if one likes to use outboard gear. Logic's I/O plugin does not compensate. We should either know the latency and use a sample delay or do it with the "Latency Fixer" (if that is the correct name of that plugin). ___ Peter Ostry

On Nov 23, 2006, at 3:36 AM, "Paul Najar" pnajar@bigpond.net.au wrote: > It seems that Apogee Symphony is state of the art in at least two of > these areas - conversion & latency. The Apogee Symphony card does not do any conversion at all. Symphony is a PCIe card that acts as a bridge between an Apogee 16x or Rosetta series converter with optional X-Symphony card and a Mac Pro. http://www.apogeedigital.com/products/symphony.php You can think of it the way you would think of a MOTU PCI-424 system, in which there are a number of possible converter boxes which can connect to the MOTU PCI-424 card that gets the audio into the computer. The difference of course is that there are more expensive components to buy for a Symphony System: 1) Apogee Rosetta or 16x converter box ($1800 - $3200) 2) X- Symphony card for converter box ($200) 3) Symphony PCIe card for Mac Pro ($900) Orren -- Author of: • Guitar Rig 2 Power • Logic 7 Ignite • Logic Pro 7 Power http://www.courseptr.com/ptr_searchResults.cfm? searchText=orren&submit=Go

On Nov 24, 2006, at 1:26 AM, Orren Merton wrote: > The Apogee Symphony card does not do any conversion at all. > > Symphony is a PCIe card that acts as a bridge between an Apogee 16x > or Rosetta series converter with optional X-Symphony card and a Mac > Pro. > http://www.apogeedigital.com/products/symphony.php > > You can think of it the way you would think of a MOTU PCI-424 system, > in which there are a number of possible converter boxes which can > connect to the MOTU PCI-424 card that gets the audio into the > computer. > > The difference of course is that there are more expensive components > to buy for a Symphony System: > 1) Apogee Rosetta or 16x converter box ($1800 - $3200) > 2) X- Symphony card for converter box ($200) > 3) Symphony PCIe card for Mac Pro ($900) All kind of out of my range at the moment, but maybe this will kick RME in the ass and get them to respond with better drivers for their PCIe cards or (if drivers alone won't do it) some adjustments to their next generation of PCIe cards.

Orren Merton <orren@...> wrote: >The Apogee Symphony card does not do any conversion at all. > >Symphony is a PCIe card that acts as a bridge between an Apogee 16x >or Rosetta series converter with optional X-Symphony card and a Mac >Pro. >http://www.apogeedigital.com/products/symphony.php > >You can think of it the way you would think of a MOTU PCI-424 system, >in which there are a number of possible converter boxes which can >connect to the MOTU PCI-424 card that gets the audio into the >computer. > > The difference of course is that there are more expensive components > to buy for a Symphony System: > 1) Apogee Rosetta or 16x converter box ($1800 - $3200) > 2) X- Symphony card for converter box ($200) > 3) Symphony PCIe card for Mac Pro ($900) > > Orren Yes, I was checking this out myself, last night. In order for me to have the lower-end Apogee Rosetta system, I would need to spend over $1000.00 more for what I paid for the FireFace800, and use up another PCI-X Card space. So, I guess I can live with the 2 ms. of Latency difference between the two systems. I believe the Latency difference really has to do with PCI-X and Firewire Bus differences, more than anything else. I also installed the AU Lab 1.0.2 version Xcode application from my Macbook. AU Lab 1.0.2 will be on the newer OS X.4 Installer Disks as part of the Xcode Tools that is offered. In order to get AU Lab you only need to install the 180 MB "Developer Tools Software" folder; you don't need the entire Xcode package. Why doesn't Apple just allow Mac owners to download the newer versions of Xcode? It should be offered in "Software Updates" or at least available on the Apple's Downloads Page. Some of these tools are useful, whether you're a Developer or not. Difference between AU Lab 1.0 and 1.0.2.... none really noticed. Maybe a little faster at scanning Plug-Ins and Devices, plus it's Mactel compatible. Results are exactly the same for Latency. 128 buffer = 461 samples for me. However, I can work at a 64 buffer most of the time with a respectible 333 samples. I can deal. Cheers Jonathan

On Nov 23, 2006, at 11:59 AM, jonathankek2000 wrote: > > Yes, I was checking this out myself, last night. In order for me to > have the lower-end Apogee Rosetta system, I would need to spend over > $1000.00 more for what I paid for the FireFace800, and use up another > PCI-X Card space. So, I guess I can live with the 2 ms. of Latency > difference between the two systems. Symphony et al probably only makes sense if you're planning on working with a lot of simultaneous channels (16 or more) and have significant routing requirements. I'm planning on using the Symphony as a digital patchbay as well; the 16x combo in this configuration gives 16 analog ins/outs as well as 16 digital ins/outs, so all of my AES-connected gear will go via the Symphony to allow flexible patching. This stuff is really trying to compete with PTHD, and is probably not cost-effective for smaller setups. --Dave

>Why doesn't Apple just allow Mac owners to download the newer versions >of Xcode? It should be offered in "Software Updates" or at least >available on the Apple's Downloads Page. Some of these tools are >useful, whether you're a Developer or not. You can join up to the developer program for free, however, and download it that way. And note that there is some other interesting stuff in the developer tools for non-developers (or at least, not 'real' developers) - notably Quartz Composer, which is catching on as a VJ tool. (though I'm a 'real' developer myself - XCode has a place on my dock). Cheers David

On 24/11/2006, at 3:44 AM, dennis gunn wrote: > All kind of out of my range at the moment, but maybe this will kick > RME in the ass and get them to respond with better drivers for their > PCIe cards or (if drivers alone won't do it) some adjustments to > their next generation of PCIe cards. Has RME announced any PCIe solutions? ::::::::::::::::::::::::::::::::::::::::::::::::::: Paul Najar Jaminajar Music Production www.jaminajar.com

On 24/11/2006, at 3:26 AM, Orren Merton wrote: > > On Nov 23, 2006, at 3:36 AM, "Paul Najar" pnajar@bigpond.net.au > wrote: > >> It seems that Apogee Symphony is state of the art in at least two of >> these areas - conversion & latency. > > The Apogee Symphony card does not do any conversion at all. > > Symphony is a PCIe card that acts as a bridge between an Apogee 16x > or Rosetta series converter with optional X-Symphony card and a Mac > Pro. > http://www.apogeedigital.com/products/symphony.php > > You can think of it the way you would think of a MOTU PCI-424 system, > in which there are a number of possible converter boxes which can > connect to the MOTU PCI-424 card that gets the audio into the > computer. > > The difference of course is that there are more expensive components > to buy for a Symphony System: > 1) Apogee Rosetta or 16x converter box ($1800 - $3200) > 2) X- Symphony card for converter box ($200) > 3) Symphony PCIe card for Mac Pro ($900) Thanks for the clarification Orren. I did actually mean Symphony + converters... Kind regards ::::::::::::::::::::::::::::::::::::::::::::::::::: Paul Najar Jaminajar Music Production www.jaminajar.com

On 24/11/2006, at 5:11 PM, Dave Katz wrote: > > On Nov 23, 2006, at 11:59 AM, jonathankek2000 wrote: > >> >> Yes, I was checking this out myself, last night. In order for me to >> have the lower-end Apogee Rosetta system, I would need to spend over >> $1000.00 more for what I paid for the FireFace800, and use up another >> PCI-X Card space. So, I guess I can live with the 2 ms. of Latency >> difference between the two systems. > > Symphony et al probably only makes sense if you're planning on > working with a lot of simultaneous channels (16 or more) and have > significant routing requirements. I'm planning on using the Symphony > as a digital patchbay as well; the 16x combo in this configuration > gives 16 analog ins/outs as well as 16 digital ins/outs, so all of my > AES-connected gear will go via the Symphony to allow flexible > patching. > > This stuff is really trying to compete with PTHD, and is probably not > cost-effective for smaller setups. It's really the high end of native systems. Can you answer me a couple of questions about the software (Maestro?) that controls it that I don't seem to work out from Apogee's site. Does Maestro have remote midi control support? Does it have a monitor section? Many thanks. ::::::::::::::::::::::::::::::::::::::::::::::::::: Paul Najar Jaminajar Music Production www.jaminajar.com

On 24/11/2006, at 6:59 AM, jonathankek2000 wrote: > Difference between AU Lab 1.0 and 1.0.2.... none really noticed. Maybe > a little faster at scanning Plug-Ins and Devices, plus it's Mactel > compatible. Results are exactly the same for Latency. 128 buffer = 461 > samples for me. However, I can work at a 64 buffer most of the time > with a respectible 333 samples. I had Au Lab 1.0 and noticed occasional crashes when instanciating plugins. I DL'd the latest Xcaode (almost 1GB) just to make sure I have the latest AU Lab version - 1.0.3 as it turns out but haven't been using it long enough to notice any difference. ::::::::::::::::::::::::::::::::::::::::::::::::::: Paul Najar Jaminajar Music Production www.jaminajar.com

On Nov 24, 2006, at 10:36 PM, Paul Najar wrote: > > Does Maestro have remote midi control support? Nope. > Does it have a monitor > section? Not sure what you mean by that. It does have a low-latency mixer and routing stuff. Can you be more specific? --Dave

On 25/11/2006, at 6:10 PM, Dave Katz wrote: >> Does it have a monitor >> section? > > Not sure what you mean by that. It does have a low-latency mixer and > routing stuff. Can you be more specific? Like the monitor section on a analog console. Speaker switching, talkback, control room volume, monitoring of different paths etc... While on it can you store presets of whole matrix setups? Thanks for your answers Kind regards ::::::::::::::::::::::::::::::::::::::::::::::::::: Paul Najar Jaminajar Music Production www.jaminajar.com

On Nov 25, 2006, at 4:19 PM, Paul Najar wrote: > > On 25/11/2006, at 6:10 PM, Dave Katz wrote: > >>> Does it have a monitor >>> section? >> >> Not sure what you mean by that. It does have a low-latency mixer and >> routing stuff. Can you be more specific? > > Like the monitor section on a analog console. Speaker switching, > talkback, control room volume, monitoring of different paths etc... Think of it as a big digital audio I/O pipe (32 channels, bidirectional, at up to 192K.) There is no analog section whatsoever. You then have to hook something to the bus (Apogee converters, or another Mac/Symphony combo) to make it do much of anything useful. With the original software you could patch any of the channels to any ins/outs of your DAW, plus a (near-)zero latency digital mixer (which you'd mix to a pair of output channels and externally connect that to your monitoring system, for example.) They've just added the V-bus thing, where you can create virtual channels on the DAW side (so you can patch applications together via the Symphony card, which is of course brain-dead architecturally, as it should just happen in software, but what do I know.) What has been promised but I don't think is there yet (though I haven't had a chance to try the latest release) is a full patch matrix on the outboard side, essentially replacing an AES patchbay, while providing mults and such. You could do a lot of what you listed if you had enough converter channels (putting each set of speakers through a different pair of DACs, for example) but it's probably not the most effective way to do it. > > While on it can you store presets of whole matrix setups? Yep. --Dave

To everyone contributing to this post, thanks. It has been very interesting. I do want to make certain I am not making a mistake by making an assumption about hardware monitoring: Back in the days when ADATs were state of the art, I wondered how there internal processors were fast enough to get up to 128 tracks in sync and in and out. (especially given that the data was not written to tape in continuous stripes but rather in chunks as the VHS record head rotated) I spoke with a tech at Alesis and he basically said there was internally an internal delay (or buffer) on every unit that did the math to sync the newly recorded signals with those already on tape, and that also assemble the playback data, so this wasn't anything I every thought about then. Now I am primarily a music teacher and location recordist using Logic Express to record my students and live concerts. When I began using Logic Express I immediately noticed the latency of software monitoring but I viewed it in the same light as monitoring the playback head in the days of analog tape, and so it was expected and made sense to me. (Back then if you tried to record tracks while monitoring the playback head you would be off by the time proportional to the physical space between record and playback head) Since then I have always used hardware monitoring while recording tracks and have added the Lexicon MX200 for adding (monitoring only) effects while tracking and I love it. I have assumed that the same sort of math the ADATs were doing is also happening with Logic as everything seems to work fine (perfectly in sync) as long as I use hardware monitoring and play with what I hear. Am I correct? I must admit that I am concerned about my FF800 as it indicated in its own manual that there is about 2ms of latency even when monitoring directly, but for my uses that seems pretty imperceptible, but hopefully it too is accounted for somewhere in this complex chain? Your comments are appreciated! Stuart Holmes Holmestudio Music Poway CA

I just want to make sure that all SID XL users are aware that the Halion Player has been updated and it is now working under Logic 7.23. Finally, I was starting to lose hope.

--- In logic-users@yahoogroups.com, Stuart Holmes <stumusic@...> wrote: > To everyone contributing to this post, thanks. It has been very > interesting. I do want to make certain I am not making a mistake by > making an assumption about hardware monitoring: Let's define our terms a little, for the purposes of this discussion: Source-monitoring - monitoring completely in the analog domain, by listening to the acoustic source, or through a totally analog mixer path. Any delays are in the microsecond realm and completely unnoticeable, by anyone. Hardware monitoring - monitoring via the hardware audio interface or digital mixer. Some A/D/A delay and possibly a small buffer is involved. Delays are generally up to a 2-3 milliseconds, and may cause noticeable phase discrepancies or subtle diferences in a tight groove. Software monitoring - monitoring by taking a trip through the computer and a software host application. A/D/A, hardware and software buffers are involved. Delays may be anywhere from a couple of milliseconds up to significant fractions of a second, and may be very noticeable for many performers. > everything seems to work fine (perfectly in sync) as long as I use > hardware monitoring and play with what I hear. Am I correct? If you have measured and set the "record delay" in Logic to compensate for record offset (if any), yes. > I am concerned about my FF800 as it indicated in its own > manual that there is about 2ms of latency even when monitoring > directly, but for my uses that seems pretty imperceptible, but > hopefully it too is accounted for somewhere in this complex chain? Monitoring via digital hardware is not compensated. If you want to compensate, measure the hardware monitor latency, and either ADD this to the record offset figure you already measured, or add a sample delay to the track AFTER recording. See my other recent post for more detail. John Pitcairn ---------------------------------------------------------------------------- - LC Xmu Logic/Mackie Control emulation & management, LC Xview software LC/MC display, Logic environments & stuff... Opus Locus - http://www.opuslocus.com ---------------------------------------------------------------------------- -

On 26/11/2006, at 1:33 PM, Dave Katz wrote: > > Think of it as a big digital audio I/O pipe (32 channels, > bidirectional, at up to 192K.) There is no analog section > whatsoever. You then have to hook something to the bus (Apogee > converters, or another Mac/Symphony combo) to make it do much of > anything useful. Thanks for your response Dave. I understand it needs converters to talk to the outside world - but that said for anyone using it with converters these features become potentially useful for many of us. Where my ideas are coming from is the RME software control panel called Totalmix. It offers all the things I mention including midi remote control over everything - and thus control surface support. In my own studio this software has eliminated the need for me to buy a standalone analog monitoring solution like Mackie's Big Knob or many others... and in the process it actually does a -better job- than any analog solution because of the digital accuracy in attenuating stereo signals to control room monitors etc. > With the original software you could patch any of the channels to any > ins/outs of your DAW, plus a (near-)zero latency digital mixer (which > you'd mix to a pair of output channels and externally connect that to > your monitoring system, for example.) > > They've just added the V-bus thing, where you can create virtual > channels on the DAW side (so you can patch applications together via > the Symphony card, which is of course brain-dead architecturally, as > it should just happen in software, but what do I know.) > > What has been promised but I don't think is there yet (though I > haven't had a chance to try the latest release) is a full patch > matrix on the outboard side, essentially replacing an AES patchbay, > while providing mults and such. > > You could do a lot of what you listed if you had enough converter > channels (putting each set of speakers through a different pair of > DACs, for example) but it's probably not the most effective way to do > it. I see. Sadly it would all have to be mouse or keyboard switched though as midi or other remote control is not possible. My intention is not to start a features shoot out, but because of how well designed the RME software is IMO and better than any other I've seen I'm always curious to see weather a new high end device like Symphony is offering similar functionality because it really does make a significant difference to what is possible with the hardware. And this information is not offered at Apogee's site. In the same way that this thread has exposed to many more people the importance of certain features in interface specification/ performance I feel that the software design end of things also needs to be exposed so makers are forced to improve this side of the equation as well. Kind regards ::::::::::::::::::::::::::::::::::::::::::::::::::: Paul Najar Jaminajar Music Production www.jaminajar.com

On Nov 26, 2006, at 3:15 PM, Paul Najar wrote: > > Where my ideas are coming from is the RME software control panel > called Totalmix. It offers all the things I mention including midi > remote control over everything - and thus control surface support. In > my own studio this software has eliminated the need for me to buy a > standalone analog monitoring solution like Mackie's Big Knob or many > others... and in the process it actually does a -better job- than any > analog solution because of the digital accuracy in attenuating stereo > signals to control room monitors etc. Ah, now I get it. It looks like the major technical differences between the RME stuff and the Apogee stuff (Maestro) is the lack of MIDI control over the faders, and the fact that you're limited to two mixes. FWIW, the downside to digital monitor control is the bit-crushing that takes place at low volumes (since you're leaving the analog gain up and scaling down the samples in the digital realm.) The Crane Song Avocet's response to this, while giving precise level recall, was to replace the volume pot with a network of precision resistors and a bunch of relays under digital control. They also give you a couple of analog pads to stick in the back of your power amps so that you can run the level as hot as possible. (A rather pricey approach, of course.) It will be interesting to see what Apogee does with Maestro, which is very early in its development now. Perhaps they'll add more features over time (no telling what the limitations of the hardware mixing is, however.) I'm hazarding a guess that Apogee figures that hardware monitoring will go away for most folks with the latest generation of computers, as the latency for software monitoring becomes negligible. --Dave > >

On 27/11/2006, at 12:02 PM, Dave Katz wrote: > FWIW, the downside to digital monitor control is the bit-crushing > that takes place at low volumes (since you're leaving the analog gain > up and scaling down the samples in the digital realm.) The Crane > Song Avocet's response to this, while giving precise level recall, > was to replace the volume pot with a network of precision resistors > and a bunch of relays under digital control. They also give you a > couple of analog pads to stick in the back of your power amps so that > you can run the level as hot as possible. (A rather pricey approach, > of course.) I'm aware of the bit crush issue but have discovered just how small a range of volumes I need and work towards it by setting my HR824's input fairly low so I'm pushing the Multiface's outs pretty hard most of the time - also has the added benefit of not being able to blow them up from too much drive easily. I'm also not sure about how RME do the maths on attenuating their outputs but would not be a bit surprised if they have addressed this issue somehow because even at low volume the playback seems pretty clear. Not at all like a bitcrusher plugin when you drop the number of bits... Kind regards ::::::::::::::::::::::::::::::::::::::::::::::::::: Paul Najar Jaminajar Music Production www.jaminajar.com

--- In logic-users@yahoogroups.com, "HKC" <hkc@...> wrote: > > I just want to make sure that all SID XL users are aware that the Halion Player has been updated and it is now working under Logic 7.23. > Finally, I was starting to lose hope. > Whoooweee!!! Thanks for the notice. I'm using 7.21, so I'll see how it works under that.