[commit?] Patch allows separate input and output audio device (on Mac)
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
[commit?] Patch allows separate input and output audio device (on Mac)
by Dan Stowell
::
Rate this Message:
I've just applied this patch on my Intel Mac at work, and it works smoothly.
I'd like to suggest that we commit this patch. It will be a great advantage for beginners at SC, given that Intel Macs are so common now, not to have to fiddle with strangely-named settings in their Audio Midi Setup. Comments and further test reports welcome. Dan 2008/6/29 Axel Balley <a.balley@...>: > A few words about the cleanup in the last patch : the CoreAudio driver class > now holds only one mDevice member as well as one streamDesc. All calls to > UseSeparateIO() are now unnecessary since there's one device only. > Axel > > Axel Balley writes: >> >> Since the CoreAudio driver now never runs in a state where the inputDevice >> is different from the outputDevice (the aggregate takes over in that case), >> the code can be cleaned up quite a bit. Also, the server will now print out >> the names of the subdevices of the aggregate before the input and output >> streams are listed. >> Attached is the latest patch that combines this and previous changes. >> Feedback is welcome ! >> Cheers, >> Axel >> Dan Stowell writes: >>> >>> 2008/6/28 Axel Balley <a.balley@...>: >>>> >>>> Dan Stowell writes: >>>>> >>>>> A couple of minor issues, non-show-stopping: >>>>> (1) The aggregate device contains the inputs and outputs of both >>>>> devices, rather than the input of one device, and the output of the >>>>> other. This is actually pretty cool on my PPC Mac because I get lots >>>>> of ins and lots of outs when adding the builtin to my firewire box. On >>>>> Intel Mac with no explicit choices of device, I'm assuming that you >>>>> end up with the expected behaviour, i.e. built-in-input and the >>>>> built-in output - are you on Intel, Axel, and does that happen for >>>>> you? >>>> >>>> As far as I know about aggregate devices, you can't create an aggregate >>>> that >>>> only holds a subset of the inputs/outputs of the subdevices in it. You >>>> get >>>> all of them in one device. >>> >>> Yes, that's right. Given what you say (below) about default Intel >>> behaviour I think this is fine, although we might want to think about >>> this further. Hopefully others will try it out using the attached >>> patch :) >>> >>>> I'm on Intel by the way, and the patch behaves as expected with the >>>> built-in >>>> input/output devices (I end up with one device that has one In and one >>>> Out). >>>> If my default OS devices are Built-In Mic and Firepod, I get an >>>> aggregate >>>> that has : >>>> Ins : 10 Firepod Ins + 1 Built-in Mic >>>> Outs : 10 Firepod Outs >>>> This can be confusing though, and it's why I'd still like to investigate >>>> how >>>> hard it would be to deal with two devices without going the aggregate >>>> way. >>>> I'm guessing it could bring up plenty of problems regarding sample rate >>>> mismatch or syncronisation. Still, it seems like the Core Audio driver >>>> for >>>> SC was designed with multiple devices in mind, so maybe it'd be good to >>>> hear >>>> from jmc himself about this matter. >>> >>> Understood. Yes, the code re separate devices is tantalising. However, >>> the Aggregate Device mechanism does some nice things for us that might >>> need to be re-implemented in SC code if we avoid ADs (bleh). And the >>> vestigial code might be vestigial for a reason...? >>> >>>>> (2) The "SCAggregate" device appears in the list if I open up my >>>>> "Audio MIDI Setup" panel (while the server is booted, at least). We >>>>> should probably make it private, that sound OK? Better than confusing >>>>> users with mysterious things appearing. I can't right now spot the >>>>> tweak for that, but I was reading it yesterday... >>>> >>>> That seems better to me too. I'll give it a look. >>> >>> OK, I've found it. In the CFDictionary used to request the AD, you >>> just add a key "private"=>1. I've added this to the code. >>> Attached is a patch for what we have so far. So it combines our two >>> patches, plus (a) setting the AD as private, (b) SC_Jack.cpp update to >>> match, (c) two-devices option only active for Mac. Comments welcome. >>> Dan >>> >>>>> 2008/6/26 Axel Balley <a.balley@...>: >>>>>> >>>>>> One more time, this time with proper CFRelease of intermediary >>>>>> objects... >>>>>> >>>>>> Le 27 juin 08 à 00:47, Axel Balley a écrit : >>>>>>> >>>>>>> To give credit where it's due, the idea of creating Aggregate Devices >>>>>>> on >>>>>>> the fly was from Scott on the users list. Anyway, attached is a patch >>>>>>> with a >>>>>>> quick hack at it. >>>>>>> When no hardware device is selected at launch, the server chooses the >>>>>>> system default input and output. Up until now, there was no way of >>>>>>> getting >>>>>>> input to work when those two devices were different. >>>>>>> With this patch, the server automatically creates an aggregate device >>>>>>> of >>>>>>> the input and output when it is necessary (i.e they are different >>>>>>> devices). >>>>>>> The aggregate is then selected as the new input/output. It is >>>>>>> destroyed >>>>>>> on >>>>>>> release of the server. >>>>>>> Note that if the server crashes, you'll have to cleanup the Aggregate >>>>>>> Device yourself in the Audio MIDI Setup utility. Also, the auto >>>>>>> aggregation >>>>>>> is not done when the user specifies a device at launch (this doesn't >>>>>>> make >>>>>>> use of Dan's patch yet). >>>>>>> This works on my Leopard, let me know how it does on your system. >>>>>>> <AutoAggregate.patch.txt> >>>>>>> Cheers, >>>>>>> Axel >>>>>>> Le 26 juin 08 à 19:33, Dan Stowell a écrit : >>>>>>>> >>>>>>>> 2008/6/26 nescivi <nescivi@...>: >>>>>>>>> >>>>>>>>> On Thursday 26 June 2008 06:21:56 Dan Stowell wrote: >>>>>>>>>> >>>>>>>>>> Axel's right, there is some vestigial code which seems to prepare >>>>>>>>>> for >>>>>>>>>> separate input/output devices. We should get this working. >>>>>>>>>> It's probably quite true that the need to piss around with >>>>>>>>>> Aggregate >>>>>>>>>> Devices could put new users off very easily, so I'd argue this is >>>>>>>>>> a >>>>>>>>>> pretty important issue. We should make the first-time experience >>>>>>>>>> as >>>>>>>>>> smooth and pleasant as possible. >>>>>>>>>> Attached is a patch which gets us close-ish to supporting this. It >>>>>>>>>> shouldn't break anything - the default behaviour remains the same, >>>>>>>>>> and >>>>>>>>>> you can use s.options.device to set/get the audio device for both >>>>>>>>>> I & >>>>>>>>>> O. However, you can also use s.options.deviceIn and >>>>>>>>>> s.options.deviceOut to set them independently. >>>>>>>>>> It seems to work, to the extent that scsynth will boot and confirm >>>>>>>>>> that it's connected to X for input and Y for output. However, >>>>>>>>>> running >>>>>>>>>> code like {AudioIn.ar(1)}.play doesn't work - output works fine >>>>>>>>>> but >>>>>>>>>> scsynth doesn't seem to be taking the audio input data, not on my >>>>>>>>>> system at least. (It all works fine if input==output) >>>>>>>>>> (I'm testing this on a PPC Mac, switching between built-in audio >>>>>>>>>> and >>>>>>>>>> an Edirol FA-66 box.) >>>>>>>>>> Can anyone report success/failure using this patch (e.g. on an >>>>>>>>>> Intel >>>>>>>>>> Mac)? >>>>>>>>>> And can anyone help get it fully working? >>>>>>>>> >>>>>>>>> This patch would require changes also in SC_Jack.cpp and probably >>>>>>>>> also >>>>>>>>> changes >>>>>>>>> in for the windows backend. >>>>>>>> >>>>>>>> Thanks for pointing that out. They're simple find-and-replace >>>>>>>> changes >>>>>>>> so that's OK. The Windows I *think* is OK since I think it uses the >>>>>>>> Portaudio code which is in SC_CoreAudio.cpp (!). >>>>>>>>> >>>>>>>>> Having different audio backends on Linux, doesn't make much sense, >>>>>>>>> since >>>>>>>>> it >>>>>>>>> would fail anyways, if they are not tied to the same sync. Besides, >>>>>>>>> JACK >>>>>>>>> gives you all the flexibility you need. >>>>>>>> >>>>>>>> Yes. I was thinking of maybe adding a preprocessor switch, so that >>>>>>>> the >>>>>>>> commandline arg parser doesn't look for a second device name, on >>>>>>>> non-Mac platforms...? >>>>>>>>> >>>>>>>>> I am guessing that also on Mac you'd need to have the two cards >>>>>>>>> sync'ed >>>>>>>>> somehow, if it is not the built-in audio (assuming the built-in >>>>>>>>> audio >>>>>>>>> is >>>>>>>>> actually the same device, just with different interfaces in the >>>>>>>>> OS). >>>>>>>>> Can you normally make working aggregate devices between a built-in >>>>>>>>> soundcard >>>>>>>>> and an external one, without having them share a clock? >>>>>>>> >>>>>>>> In an aggregate device you nominate where the clock comes from. You >>>>>>>> can also opt for resampling to be done, which I guess might handle >>>>>>>> mismatched sample-rates. So, rather than handling this kind of >>>>>>>> business in scsynth's code, maybe instead we should create an >>>>>>>> on-the-fly aggregate device (as suggested by Axel) so as to benefit >>>>>>>> from their tricks. >>>>>>>> Dan >>>>>>>> _______________________________________________ >>>>>>>> sc-dev mailing list >>>>>>>> info (subscribe and unsubscribe): >>>>>>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>>>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ >>>>>>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >>>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> http://www.mcld.co.uk >>>>> _______________________________________________ >>>>> sc-dev mailing list >>>>> info (subscribe and unsubscribe): >>>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ >>>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >>>> >>>> _______________________________________________ >>>> sc-dev mailing list >>>> >>>> info (subscribe and unsubscribe): >>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ >>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >>> >>> >>> >>> -- >>> http://www.mcld.co.uk > > _______________________________________________ > sc-dev mailing list > > > info (subscribe and unsubscribe): > http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 > archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ > search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ > -- http://www.mcld.co.uk _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: [commit?] Patch allows separate input and output audio device (on Mac)
by Josh Parmenter
::
Rate this Message:
I say yes!
Josh On Jun 30, 2008, at 1:30 AM, Dan Stowell wrote: > I've just applied this patch on my Intel Mac at work, and it works > smoothly. > > I'd like to suggest that we commit this patch. It will be a great > advantage for beginners at SC, given that Intel Macs are so common > now, not to have to fiddle with strangely-named settings in their > Audio Midi Setup. > > Comments and further test reports welcome. > > Dan > > > 2008/6/29 Axel Balley <a.balley@...>: >> A few words about the cleanup in the last patch : the CoreAudio >> driver class >> now holds only one mDevice member as well as one streamDesc. All >> calls to >> UseSeparateIO() are now unnecessary since there's one device only. >> Axel >> >> Axel Balley writes: >>> >>> Since the CoreAudio driver now never runs in a state where the >>> inputDevice >>> is different from the outputDevice (the aggregate takes over in >>> that case), >>> the code can be cleaned up quite a bit. Also, the server will now >>> print out >>> the names of the subdevices of the aggregate before the input and >>> output >>> streams are listed. >>> Attached is the latest patch that combines this and previous >>> changes. >>> Feedback is welcome ! >>> Cheers, >>> Axel >>> Dan Stowell writes: >>>> >>>> 2008/6/28 Axel Balley <a.balley@...>: >>>>> >>>>> Dan Stowell writes: >>>>>> >>>>>> A couple of minor issues, non-show-stopping: >>>>>> (1) The aggregate device contains the inputs and outputs of both >>>>>> devices, rather than the input of one device, and the output of >>>>>> the >>>>>> other. This is actually pretty cool on my PPC Mac because I get >>>>>> lots >>>>>> of ins and lots of outs when adding the builtin to my firewire >>>>>> box. On >>>>>> Intel Mac with no explicit choices of device, I'm assuming that >>>>>> you >>>>>> end up with the expected behaviour, i.e. built-in-input and the >>>>>> built-in output - are you on Intel, Axel, and does that happen >>>>>> for >>>>>> you? >>>>> >>>>> As far as I know about aggregate devices, you can't create an >>>>> aggregate >>>>> that >>>>> only holds a subset of the inputs/outputs of the subdevices in >>>>> it. You >>>>> get >>>>> all of them in one device. >>>> >>>> Yes, that's right. Given what you say (below) about default Intel >>>> behaviour I think this is fine, although we might want to think >>>> about >>>> this further. Hopefully others will try it out using the attached >>>> patch :) >>>> >>>>> I'm on Intel by the way, and the patch behaves as expected with >>>>> the >>>>> built-in >>>>> input/output devices (I end up with one device that has one In >>>>> and one >>>>> Out). >>>>> If my default OS devices are Built-In Mic and Firepod, I get an >>>>> aggregate >>>>> that has : >>>>> Ins : 10 Firepod Ins + 1 Built-in Mic >>>>> Outs : 10 Firepod Outs >>>>> This can be confusing though, and it's why I'd still like to >>>>> investigate >>>>> how >>>>> hard it would be to deal with two devices without going the >>>>> aggregate >>>>> way. >>>>> I'm guessing it could bring up plenty of problems regarding >>>>> sample rate >>>>> mismatch or syncronisation. Still, it seems like the Core Audio >>>>> driver >>>>> for >>>>> SC was designed with multiple devices in mind, so maybe it'd be >>>>> good to >>>>> hear >>>>> from jmc himself about this matter. >>>> >>>> Understood. Yes, the code re separate devices is tantalising. >>>> However, >>>> the Aggregate Device mechanism does some nice things for us that >>>> might >>>> need to be re-implemented in SC code if we avoid ADs (bleh). And >>>> the >>>> vestigial code might be vestigial for a reason...? >>>> >>>>>> (2) The "SCAggregate" device appears in the list if I open up my >>>>>> "Audio MIDI Setup" panel (while the server is booted, at >>>>>> least). We >>>>>> should probably make it private, that sound OK? Better than >>>>>> confusing >>>>>> users with mysterious things appearing. I can't right now spot >>>>>> the >>>>>> tweak for that, but I was reading it yesterday... >>>>> >>>>> That seems better to me too. I'll give it a look. >>>> >>>> OK, I've found it. In the CFDictionary used to request the AD, you >>>> just add a key "private"=>1. I've added this to the code. >>>> Attached is a patch for what we have so far. So it combines our two >>>> patches, plus (a) setting the AD as private, (b) SC_Jack.cpp >>>> update to >>>> match, (c) two-devices option only active for Mac. Comments >>>> welcome. >>>> Dan >>>> >>>>>> 2008/6/26 Axel Balley <a.balley@...>: >>>>>>> >>>>>>> One more time, this time with proper CFRelease of intermediary >>>>>>> objects... >>>>>>> >>>>>>> Le 27 juin 08 à 00:47, Axel Balley a écrit : >>>>>>>> >>>>>>>> To give credit where it's due, the idea of creating Aggregate >>>>>>>> Devices >>>>>>>> on >>>>>>>> the fly was from Scott on the users list. Anyway, attached is >>>>>>>> a patch >>>>>>>> with a >>>>>>>> quick hack at it. >>>>>>>> When no hardware device is selected at launch, the server >>>>>>>> chooses the >>>>>>>> system default input and output. Up until now, there was no >>>>>>>> way of >>>>>>>> getting >>>>>>>> input to work when those two devices were different. >>>>>>>> With this patch, the server automatically creates an >>>>>>>> aggregate device >>>>>>>> of >>>>>>>> the input and output when it is necessary (i.e they are >>>>>>>> different >>>>>>>> devices). >>>>>>>> The aggregate is then selected as the new input/output. It is >>>>>>>> destroyed >>>>>>>> on >>>>>>>> release of the server. >>>>>>>> Note that if the server crashes, you'll have to cleanup the >>>>>>>> Aggregate >>>>>>>> Device yourself in the Audio MIDI Setup utility. Also, the auto >>>>>>>> aggregation >>>>>>>> is not done when the user specifies a device at launch (this >>>>>>>> doesn't >>>>>>>> make >>>>>>>> use of Dan's patch yet). >>>>>>>> This works on my Leopard, let me know how it does on your >>>>>>>> system. >>>>>>>> <AutoAggregate.patch.txt> >>>>>>>> Cheers, >>>>>>>> Axel >>>>>>>> Le 26 juin 08 à 19:33, Dan Stowell a écrit : >>>>>>>>> >>>>>>>>> 2008/6/26 nescivi <nescivi@...>: >>>>>>>>>> >>>>>>>>>> On Thursday 26 June 2008 06:21:56 Dan Stowell wrote: >>>>>>>>>>> >>>>>>>>>>> Axel's right, there is some vestigial code which seems to >>>>>>>>>>> prepare >>>>>>>>>>> for >>>>>>>>>>> separate input/output devices. We should get this working. >>>>>>>>>>> It's probably quite true that the need to piss around with >>>>>>>>>>> Aggregate >>>>>>>>>>> Devices could put new users off very easily, so I'd argue >>>>>>>>>>> this is >>>>>>>>>>> a >>>>>>>>>>> pretty important issue. We should make the first-time >>>>>>>>>>> experience >>>>>>>>>>> as >>>>>>>>>>> smooth and pleasant as possible. >>>>>>>>>>> Attached is a patch which gets us close-ish to supporting >>>>>>>>>>> this. It >>>>>>>>>>> shouldn't break anything - the default behaviour remains >>>>>>>>>>> the same, >>>>>>>>>>> and >>>>>>>>>>> you can use s.options.device to set/get the audio device >>>>>>>>>>> for both >>>>>>>>>>> I & >>>>>>>>>>> O. However, you can also use s.options.deviceIn and >>>>>>>>>>> s.options.deviceOut to set them independently. >>>>>>>>>>> It seems to work, to the extent that scsynth will boot and >>>>>>>>>>> confirm >>>>>>>>>>> that it's connected to X for input and Y for output. >>>>>>>>>>> However, >>>>>>>>>>> running >>>>>>>>>>> code like {AudioIn.ar(1)}.play doesn't work - output works >>>>>>>>>>> fine >>>>>>>>>>> but >>>>>>>>>>> scsynth doesn't seem to be taking the audio input data, >>>>>>>>>>> not on my >>>>>>>>>>> system at least. (It all works fine if input==output) >>>>>>>>>>> (I'm testing this on a PPC Mac, switching between built-in >>>>>>>>>>> audio >>>>>>>>>>> and >>>>>>>>>>> an Edirol FA-66 box.) >>>>>>>>>>> Can anyone report success/failure using this patch (e.g. >>>>>>>>>>> on an >>>>>>>>>>> Intel >>>>>>>>>>> Mac)? >>>>>>>>>>> And can anyone help get it fully working? >>>>>>>>>> >>>>>>>>>> This patch would require changes also in SC_Jack.cpp and >>>>>>>>>> probably >>>>>>>>>> also >>>>>>>>>> changes >>>>>>>>>> in for the windows backend. >>>>>>>>> >>>>>>>>> Thanks for pointing that out. They're simple find-and-replace >>>>>>>>> changes >>>>>>>>> so that's OK. The Windows I *think* is OK since I think it >>>>>>>>> uses the >>>>>>>>> Portaudio code which is in SC_CoreAudio.cpp (!). >>>>>>>>>> >>>>>>>>>> Having different audio backends on Linux, doesn't make much >>>>>>>>>> sense, >>>>>>>>>> since >>>>>>>>>> it >>>>>>>>>> would fail anyways, if they are not tied to the same sync. >>>>>>>>>> Besides, >>>>>>>>>> JACK >>>>>>>>>> gives you all the flexibility you need. >>>>>>>>> >>>>>>>>> Yes. I was thinking of maybe adding a preprocessor switch, >>>>>>>>> so that >>>>>>>>> the >>>>>>>>> commandline arg parser doesn't look for a second device >>>>>>>>> name, on >>>>>>>>> non-Mac platforms...? >>>>>>>>>> >>>>>>>>>> I am guessing that also on Mac you'd need to have the two >>>>>>>>>> cards >>>>>>>>>> sync'ed >>>>>>>>>> somehow, if it is not the built-in audio (assuming the >>>>>>>>>> built-in >>>>>>>>>> audio >>>>>>>>>> is >>>>>>>>>> actually the same device, just with different interfaces in >>>>>>>>>> the >>>>>>>>>> OS). >>>>>>>>>> Can you normally make working aggregate devices between a >>>>>>>>>> built-in >>>>>>>>>> soundcard >>>>>>>>>> and an external one, without having them share a clock? >>>>>>>>> >>>>>>>>> In an aggregate device you nominate where the clock comes >>>>>>>>> from. You >>>>>>>>> can also opt for resampling to be done, which I guess might >>>>>>>>> handle >>>>>>>>> mismatched sample-rates. So, rather than handling this kind of >>>>>>>>> business in scsynth's code, maybe instead we should create an >>>>>>>>> on-the-fly aggregate device (as suggested by Axel) so as to >>>>>>>>> benefit >>>>>>>>> from their tricks. >>>>>>>>> Dan >>>>>>>>> _______________________________________________ >>>>>>>>> sc-dev mailing list >>>>>>>>> info (subscribe and unsubscribe): >>>>>>>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>>>>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ >>>>>>>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> http://www.mcld.co.uk >>>>>> _______________________________________________ >>>>>> sc-dev mailing list >>>>>> info (subscribe and unsubscribe): >>>>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ >>>>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >>>>> >>>>> _______________________________________________ >>>>> sc-dev mailing list >>>>> >>>>> info (subscribe and unsubscribe): >>>>> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >>>>> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ >>>>> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >>>> >>>> >>>> >>>> -- >>>> http://www.mcld.co.uk >> >> _______________________________________________ >> sc-dev mailing list >> >> >> info (subscribe and unsubscribe): >> http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 >> archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ >> search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ >> > > > > -- > http://www.mcld.co.uk > > _______________________________________________ > sc-dev mailing list > > > info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 > archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ > search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ ****************************************** /* Joshua D. Parmenter http://www.realizedsound.net/josh/ “Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono */ _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: [commit?] Patch allows separate input and output audio device (on Mac)
by andrea valle-3
::
Rate this Message:
Wouldn't this mean a 3.2.something release ?
Otherwise beginners have to wait until 3.3. or to stick to realizedsound (or to svn...). ? Best -a-
-------------------------------------------------- Andrea Valle -------------------------------------------------- CIRMA - DAMS Università degli Studi di Torino --> andrea.valle@... -------------------------------------------------- " Think of it as seasoning . noise [salt] is boring . F(blah) [food without salt] can be boring . F(noise, blah) can be really tasty " (Ken Perlin on noise) |
|
|
Re: [commit?] Patch allows separate input and output audio device (on Mac)
by nescivi
::
Rate this Message:
Hi Dan,
could you attach the latest patch? it was missing from your message. Then I can check whether it breaks anything on Linux. sincerely, marije On Monday 30 June 2008 04:30:07 Dan Stowell wrote: > I've just applied this patch on my Intel Mac at work, and it works > smoothly. > > I'd like to suggest that we commit this patch. It will be a great > advantage for beginners at SC, given that Intel Macs are so common > now, not to have to fiddle with strangely-named settings in their > Audio Midi Setup. > > Comments and further test reports welcome. > > Dan > _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: [commit?] Patch allows separate input and output audio device (on Mac)
by Josh Parmenter
::
Rate this Message:
I think there was an intention to wait for 3.3 until after the book comes out. I'll wait for this patch to do a new realizedsound build, but it may be time for a 3.2.2 release...
Josh On Jun 30, 2008, at 7:35 AM, Andrea Valle wrote:
****************************************** /* Joshua D. Parmenter http://www.realizedsound.net/josh/ “Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono */ |
|
|
Re: [commit?] Patch allows separate input and output audio device (on Mac)
by Dan Stowell
::
Rate this Message:
Sorry Marije, the patch was earlier in the thread:
http://www.listarc.bham.ac.uk/lists/sc-dev/msg02579.html Regarding 3.2.2 etc: I agree that if this works nicely then it might (along with other recent improvements) be worth thinking about that. But let's wait for the patch to bed down, and for a few people to try it... Dan 2008/6/30 nescivi <nescivi@...>: > Hi Dan, > > could you attach the latest patch? > it was missing from your message. > > Then I can check whether it breaks anything on Linux. > > sincerely, > marije > > On Monday 30 June 2008 04:30:07 Dan Stowell wrote: >> I've just applied this patch on my Intel Mac at work, and it works >> smoothly. >> >> I'd like to suggest that we commit this patch. It will be a great >> advantage for beginners at SC, given that Intel Macs are so common >> now, not to have to fiddle with strangely-named settings in their >> Audio Midi Setup. >> >> Comments and further test reports welcome. >> >> Dan >> > > _______________________________________________ > sc-dev mailing list > > > info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 > archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ > search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ > -- http://www.mcld.co.uk _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: [commit?] Patch allows separate input and output audio device (on Mac)
by James Harkins-2
::
Rate this Message:
Just had another thought on this... it would be nice to be able to use the ServerOptions device string for a list of preferred devices, that is, try the first and if that's not available, fall back to the second and so on, until (if you run out of devices) just use the default set in the OS. Server.local.options.device = "MOTU UltraLite ::: Aggregate Device ::: Built-in Output"; ?? Choosing the delimiter character would be tricky though... hjh : H. James Harkins : http://www.dewdrop-world.net .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman |
|
|
Re: [commit?] Patch allows separate input and output audio device (on Mac)
by ronald kuivila
::
Rate this Message:
Hi James,
Maybe that is something that should be done in the language instead. RJK On Jul 1, 2008, at 8:36 AM, James Harkins wrote:
|
|
|
Re: [commit?] Patch allows separate input and output audio device (on Mac)
by Dan Stowell
::
Rate this Message:
No-one has ever asked for this (in my recall, anyway), whereas LOTS of
users have been thrown by the Aggregate Device issue on Intel Mac. Besides, the default device already provides this kind of mechanism, since the Mac Core Audio automatically does a fallback to other devices if the preferred is not available. Just my 2p as usual, but I'd really argue the effort is better spent elsewhere. Dan 2008/7/1, James Harkins <jamshark70@...>: > > Just had another thought on this... it would be nice to be able to use the > ServerOptions device string for a list of preferred devices, that is, try > the first and if that's not available, fall back to the second and so on, > until (if you run out of devices) just use the default set in the OS. > > Server.local.options.device = "MOTU UltraLite ::: Aggregate Device ::: > Built-in Output"; > > ?? > > Choosing the delimiter character would be tricky though... > > hjh > > > > > > > : H. James Harkins > > : jamshark70@... > > : http://www.dewdrop-world.net > > .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: > > > > > "Come said the Muse, > > Sing me a song no poet has yet chanted, > > Sing me the universal." -- Whitman > -- http://www.mcld.co.uk _______________________________________________ sc-dev mailing list info (subscribe and unsubscribe): http://swiki.hfbk-hamburg.de:8888/MusicTechnology/880 archive: http://www.listarc.bham.ac.uk/marchives/sc-dev/ search: http://www.listarc.bham.ac.uk/lists/sc-dev/search/ |
|
|
Re: [commit?] Patch allows separate input and output audio device (on Mac)
by James Harkins-2
::
Rate this Message:
On Jul 1, 2008, at 9:15 AM, ronald kuivila wrote: Hi James, Sure, that makes sense... once there is a primitive in the language to get the list of audio devices. Been discussed for a long time... maybe I missed something in the flurry of emails but I don't recall hearing about anybody doing this. hjh |
