Actually, I think I see the problem. If you seek to an offset within the same packet as the current read mark, we bypass some logic that looks important, and for a pretty dubious reason (trying to avoid unnecessarily resetting the converter). [...]]]>
Aggregate devices are really meant for one thing: doing IO. As such, aggregate devices don't provide things like channel names or controls or what have you. To access that information, you need to do it using the actual device rather than the aggregate. [...]]]>
What version of what OS are you running? What other calls to ExtAudioFile are you making before the first calls to ExtAudioFileSeek and ExtAudioFileTell? What are the sample rates of the file and the client format (if any)? Doug On Nov 5, 2009, at 23:16 , Abdul.Majeed wrote: [...] [...]]]>
hi ive made some progress with the aggregate devices, but when making an aggregate device the names of the channels in the streams seem to be lost, and get replaced with the name for the whole device.
is there a way to set the stream names (or even better preserve them automatically)? [...]]]>Hi Bill, Thanks a tone for your quick response. Please here it is more information 1. for another .mp3 file result i got as Sint64 theOffset = (primeOffset + 0); //it gives 576 ExtAudioFileSeek(fileRef,theOffset); ExtAudioFileTell(fileRef,&theOffset); [...]]]>
Jeff is correct. While all audio engines running in the built-in audio complex are derived from the same crystal, we do allow them to be at different sample rates. Best Regards, Niel Warren On Nov 5, 2009, at 12:05 PM, email@hidden wrote: Message: 8 [...]]]>
Great, Thanks for that explanation, and thanks Walt for trying to reproduce it. :o) Aristotel > Subject: Re: XCode AU project template issue > From: email@hidden > Date: Tue, 3 Nov 2009 18:01:36 -0800 > CC: email@hidden > To: email@hidden > > > Yes, that is quite true - confusion piled upon confusion. Briefly, the > problem is that auval runs in 32bit mode by default, and the release > mode is set to build native arch by default - so that builds a 64bit > version on some machines, 32bit on others). So, we need to fix the > template to set your build arch to be explicitly i386 and x86_64 > > As I said previously, we still intend to generate a document that > describes the known issues (of which this is one) and how to fix it. > That's in review at the moment - hopefully we'll have something out in > the next day > > Bill > > On Nov 3, 2009, at 3:50 PM, Aristotel Digenis wrote: > > > Hi everyone, > > > > After so many responses to my initial post, the problem I was having > > particularly has not been discussed. It seems a different bug got > > all the attention and even Michael Hopkins' response was relating to > > the AU with "Cocoa View", which is not the problem I was having. > > > > Could somebody on an Intel iMac try to use the AU plugin template > > (withOUT any view), build it, and see if auval picks up on it? I > > still don't know if I am the only one who had that problem (until > > manually fiddling with the project settings). > > > > Thanks, > > > > Aristotel > > > > > From: email@hidden > > > Date: Tue, 3 Nov 2009 16:43:47 -0700 > > > To: email@hidden > > > Subject: Re: XCode AU project template issue > > > > > > Yea, I think we're all a little frustrated at having to debug sample > > > code, which it looks like we've all taken a stab at at various > > times... > > > > > > It sounds like someone up top got the message, and we can all look > > > forward to dealing with a completely different set of issues in the > > > future. That's what we do as engineers, right, is deal with a > > bunch of > > > c**p coming from the computer so our users don't have to. :-) > > > > > > Thanks to all involved. > > > > > > \W > > > --- > > > On Nov 3, 2009, at 2:30 PM, tahome izwah wrote: > > > > > > > Whatever. If you didn't mean it that way then I apologize. I am > > > > frequently reading your messages (as I assume you do mine) so I > > can't > > > > be totally context free. At any rate, let's stick to business. > > > > > > > > --th > > > >]]>
Abdul Do you have this issue with other files, or just a particular MP3 file? Bill On Nov 5, 2009, at 5:49 AM, Abdul.Majeed wrote: [...]]]>
The solution it seems like you are looking for is to create an aggregate device that has all the built-in devices in it. There has been a lot of discussion about using aggregate devices on this list previously. On Nov 5, 2009, at 8:02 AM, audioboy 77 wrote: [...] [...]]]>
Calling ExtAudioFileDispose() on a > 2 hour large MP4 audio file causes a crash. * ExtAudioFileDispose() calls AudioFileClose() * AudioFileClose() calls MP4AudioFile::Close() * As part of closing the mp4 file, MP4AudioFile::FillGaplessString() is called [...]]]>
Hi In my application (a pro-audio effect unit/synthesizer), I want to show the Built-In devices as one physical device, with different channels representing the Microphone, Input and Output. Â To do this, I use the "related devices" property to find all subdevices and group them together. [...]]]>
Hi All, I would like to get some inputs on the issues that I am facing currently. Please correct me if I am doing something wrong as I am not expertise in this area. I was trying to read mp3 audio data in chunk by chunk manner, for that I uses ExtAudioFileRead as I want the data in uncompressed format (16 bit, linear PCM). For a specific .mp3 file (as of my test) i could see that following results for the ExtAudioFileSeek and ExtAudioFileTell apis. Sint64 theOffset = (primeOffset + 0); //it gives 576 ExtAudioFileSeek(fileRef,theOffset); ExtAudioFileTell(fileRef,&theOffset); /// theOffset gives 0 //read a sample frame of theNumPackets = 4096 ExtAudioFileRead(filRef,& theNumPackets,&BufferList); ExtAudioFileTell(fileRef,&theOffset); /// theOffset gives 4672 Could anybody please tell me ,why first call to ExtAudioFileTell returns 0 and after reading it gives 4672 (i was expecting 4096)? Also any more info about the behavior of ExtAudioFileSeek and ExtAudioFileTell apis are highly appreciated.]]>
Thank you Michael, this is good news and very much appreciated! I just wanted to add that I don't deserve credit for the modified Xcode template, I was just posting the link which is from an earlier CA message by Stephan Bernsee. I'm not sure if there's a web site for [...]]]>
On Nov 4, 2009, at 12:31 PM, Paul Davis wrote: On Wed, Nov 4, 2009 at 3:08 PM, William Stewart <email@hidden> wrote: [...] It doesn't do the utility stuff - in your reply you deleted the sentence that tells you what you need to do (I find this quite frustrating). Here it is again: [...] [...]]]>
[...] actually, i am using the apple utility library's CAAudioUnit::SetParameter method, and just noted what it does internally. it appears to ask the plugin if it has a "fast dispatch" method for setting parameters, and uses it; otherwise it just calls AudioUnitSetParameter(). [...]]]>
Its your host app that is the problem. There are two things that the host needs to do that I think you aren't doing. (1) AudioUnitSetParameter is not sufficient when you change the value of a parameter with views around. You should look through [...] [...]]]>
On Wed, Nov 4, 2009 at 1:14 AM, Richard Dobson [...] Is this really what's going on? That is not the impression I have gotten. I think there is really is no express or implied correlation between beats and quarter notes. There is a stream of beats whose [...]]]>
[...] Ah, I remember that now, thank you. I did use that during development. But to be honest, it was not as helpful as I had expected. It is based on the AUGraph part of the API, and this is not viable if you are writing a cross-platform host which loads plugins using non-AU APIs. [...]]]>
On Wed, Nov 4, 2009 at 8:15 AM, Olivier Tristan [...] We've already had users who have confirmed that the plugins behave differently in Logic and at least one other host. But I'll check AULab as well, thanks.]]>
An AU host example project is at /Developer/Examples/CoreAudio/Service/CocoaAUHost HTHThis email sent to email@hidden Follow-Ups: Re: AU, plugin tempo, musical time information From: Paul Davis <email@hidden> References: [...] [...]]]>
[...] If I were you I would check if the same issue happen in AULab (regarding factory presets). Always a good test. HTH -- Olivier Tristan Ultimate Sound Bank]]>
we have noticed in ardour that some/all Apple's AU's fail to update their GUIs when we set parameter values from automation data or when we switch factory presets. this problem has not been noticed in any other AU plugin "series" - Waves, WaveArts, PSP and many other [...]]]>
[...] thank you for clarifying this. it would be nice to see the docs updated to include some version of this sentence: [...] as a side note, i wanted to add that in general i have found the AU documentation very good when considering things from a plugin or plugin author perspective. [...]]]>
On Tue, Nov 3, 2009 at 8:56 PM, William Stewart <email@hidden> wrote: [...] For the record, it isn't "common practice". It may be an unavoidable (even necessary) technical restriction, but it is unfortunate if that is somehow claimed to reflect (in some deliberate way) what musicians do. [...]]]>
On Nov 3, 2009, at 6:47 PM, Paul Davis wrote: On Tue, Nov 3, 2009 at 8:56 PM, William Stewart <email@hidden> wrote: For a change from 3/4 to 4/8 the value of the beat does not change (thus, a 4/8 time sig will still have 2 beat values for that measure - the value of [...]]]>
[...] OK, thanks, I'll take that as a clarification. My confusion stems from the fact that I do not believe that it *is* common practice. Since the docs I was reading date from Tiger, I wondered if this had been clarified or altered since. 1 beat = 1 quarter note, so it shall be. [...] [...]]]>
Yes, that is quite true - confusion piled upon confusion. Briefly, the problem is that auval runs in 32bit mode by default, and the release mode is set to build native arch by default - so that builds a 64bit version on some machines, 32bit on others). [...]]]>
On Nov 3, 2009, at 3:57 PM, Paul Davis wrote: On Tue, Nov 3, 2009 at 4:59 PM, James McCartney [...] I'm sorry, but I don't agree at all (and this goes back to my original confusion about your post). Here's the relevant quote from the docs: [...] [...]]]>
Hi Taylor We don't know of any issues here, so can you file a bug report? Thanks Bill On Oct 31, 2009, at 10:25 AM, Taylor Holliday wrote: Interesting, upon rebooting the duet was in sync. Putting the computer to sleep and waking it back up results in it being out of sync again. [...]]]>
On Nov 3, 2009, at 4:50 PM, Aristotel Digenis wrote: > quoted text Here are my results: XCode 3.1.3 (IDE 1191.0 core 1192.0 toolsupport 1186.0) Mac OS X 10.6.1 (build 10B504) MacPro 8-core (sorry I have no iMac handy today...) 1. New project from template "Audio Unit Effect" 2. [...]]]>
[...] I'm not really attempting to argue it, although i think it is an interesting discussion, albeit not for this list. The docs are not really clear on whether on not "beat == quarter note". I asked for clarification. Doug seemed to be offering a defense of "beat == [...]]]>
Hi everyone, After so many responses to my initial post, the problem I was having particularly has not been discussed. It seems a different bug got all the attention and even Michael Hopkins' response was relating to the AU with "Cocoa View", which is not the problem I was having. [...]]]>
Yea, I think we're all a little frustrated at having to debug sample code, which it looks like we've all taken a stab at at various times... It sounds like someone up top got the message, and we can all look forward to dealing with a completely different set of issues in the future. [...]]]>
For those of you that have not been following the recent thread on the Xcode AU project templates, it has been brought to our attention that the Audio Unit Effect with Cocoa View XCode project template is not working with the release build style on Leopard with Xcode 3.1.4. [...]]]>
[...] Yes. Tempo is just an illusion. There is no tempo between <fermata /> events. Periodicity is just a means of creating expectation.]]>
[...] Well let's note* that traditional western notation itself does not make beats constant value. You have 4/4 and 8/8. Otherwise time signatures would not need a denominator at all. You'd just have a measure of 4 beats followed by 8 beats at double tempo. [...]]]>
[...] Personally, I'm not a big fan of the notion of time signature, and I wish they'd left it out of MIDI altogether instead of dragging it along by its broken neck. The metrical level of the "beat" in western music is essentially arbitrary and I approve of MIDI's attempt to circumvent this; [...]]]>
Whatever. If you didn't mean it that way then I apologize. I am frequently reading your messages (as I assume you do mine) so I can't be totally context free. At any rate, let's stick to business. This email sent to email@hidden References: [...] [...]]]>
[...] You've made a lot of self-centered assumptions, Tahome. You assume that I replied to you, you assume that I actually track your messages to this list for personal content trends, and you assume that I care whether or not you read my messages and how you react to them. [...]]]>
[...] Yep, thats absolutely true. But now go talk to musicians who work with traditonal western notation, and ask them to count backwards 8 beats from a given location. Let makes it half way through the 6/8 section. How many of them do you think are going to count quarter notes and how [...]]]>
Yes, and this is what I like about this list. Many thanks to all the kind Apple developers who are so generous for their time and advice!! This is indeed *very* much appreciated! 2009/11/3 Kyle Sluder <email@hidden>: [...]]]>
And after writing that I realized that many sequencers, of course, just choose some division of the quarter note (notice, quarter note, not beat) and count in terms of 480ths, 960ths or whatever. And that where it matters even more is when putting tempo into the [...]]]>
[...] Well at least this list has the advantage of quite a few very active engineers. Cocoa-dev, by comparison, has far fewer with respect to the specialization of said engineers and the sheer scope of discussion. This email sent to email@hidden References: [...] [...]]]>
On Nov 3, 2009, at 11:05 , Richard Dobson wrote: Doug Wyatt wrote: . [...] You're not kidding! Standard musical practice (I suspect amongst drummers too) is to divide such patterns into "squares and triangles" - 2+2+3, or 3+2+2; sometimes 4+3. [...]]]>
Kyle, I am usually the first on this list to recommend using the bugreporter and Brian knows this, so his remark was either smart assed or he was trying to p'ss me off, for whatever reason. At any rate, filing bugs is a good thing if it helps solving problems. [...]]]>
On Tue, Nov 3, 2009 at 2:05 PM, Richard Dobson [...] Indeed (see my other post just now). But if I was was ever to get into the host-writing business, it is precisely that "other mechanism" I would be interested in. You know, the sort of host for people who "think differently". [...]]]>
If the "primary division" (if we may call it that) were the eighth-note instead of the quarter-note, and the secondary division could be set variously (and dynamically) to *2 or *3 it would meet most people's needs, most of the time. It would cover all standard changes between [...]]]>
[...] hi james (long time :) ... yeah, ardour does both :) the problem is not so much which is superior as much as which one is the rule to follow when talking to an AU plugin. This email sent to email@hidden References: [...] Re: AU, plugin tempo, musical time information [...]]]>
On Tue, Nov 3, 2009 at 2:05 PM, Richard Dobson [...] in all fairness, i don't think that is the job of this API. conventional meter notation doesn't really cover this aspect of meter, and it would have to "conveyed" via some other mechanism. however, it [...]]]>
[...] FWIW, in supercollider I implemented constant beat values instead of constant note values and got complaints in the opposite direction (beats change duration across meter changes), so I think neither way is inherently superior. Also FWIW, I remember an electronic music conference ca 1984 where Yamaha was announcing their TX816 (FM synth rack) and some composing software to go with it based on a constant value *measures* having 1680 ticks or something like that. That got the composers sitting in the auditorium up in arms!]]>