Re: [Sursound] Ambisonic first approach
--On 16 November 2013 06:31 + Michael Chapman wrote: > --fiddling to get the correct one of (?)24 possible permutations of > the four capsules to the snake is a ! Especially in dim lighting > ... and you didn't bring a lamp ... and ... A dab of four coloured paints on the plugs and sockets makes this so much easier! That's why I was asking here about colour codes a few years ago (the answer is make up your own!). Paul -- Paul Hodges ___ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
Re: [Sursound] Ambisonic first approach
On 11/15/2013 07:23 PM, Len Moskowitz wrote: J?rn Nettingsmeier wrote: the tetra sounds great, but the connectors are very flimsy. The connectors are all from Switchcraft's Tini-Q (mini-XLR) series, used in many professional products and contexts. In the six years since TetraMic was introduced, we've had exactly one cable returned to us due to connector or cable failure. you are right, i should have phrased that more precisely, the connectors are actually fine, or at least not the biggest problem. the _cables_ are frightfully flimsy (which is a consequence of the small size of the 6-pin miniXLR), and they are very inconvenient to re-solder in-the-field, which i've been forced to do several times, despite handling them with the utmost care. most of these issues were a consequence of the comparably heavy PPUs which cause a great strain on the split when handled or transported. since i've taken to tying the the PPUs to a bundle, i've had no further problems, but i'm still muttering prayers before every important recording. i'd expect most users to do minor repairs themselves, hence i doubt you're getting an accurate picture of the durability of cable and split. the small 6-wire multicore is rarely used here, i prefer to go balanced as soon as i can, unless i absolutely need the mic to be as inobtrusive as possible. too often i've had slight dimmer noise in the signal during the show that was not apparent during sound check, because of changing light scenes. this means the split is attached directly to the microphone, and there is considerable handling strain while the mic is being set up, because it's hard to create an effective strain relief while retaining enough mobility for positioning. i can only re-iterate it again: i'd be willing to pay a substantial extra fee for balanced outputs from the mic body, with a road-worthy connector and more durable wiring, and i'm looking forward to the project you mentioned earlier. even if there is no upgrade path, i'd be in the market for such a tetramic 2.0. if you need a beta tester, let me know :-D best, jörn -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net ___ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
Re: [Sursound] Ambisonic first approach
At 10:03 16-11-13, Paul Hodges wrote: >--On 16 November 2013 06:31 + Michael Chapman >wrote: > >> --fiddling to get the correct one of (?)24 possible permutations of >> the four capsules to the snake is a ! Especially in dim lighting >> ... and you didn't bring a lamp ... and ... > >A dab of four coloured paints on the plugs and sockets makes this so >much easier! > >That's why I was asking here about colour codes a few years ago (the >answer is make up your own!). brown, red, orange, yellow... ? ___ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
Re: [Sursound] Linux ambdec b-format channel order
I encountered this a while back and modified my copy of Ambdec 0.5.1 to register its inputs with jack in FuMa order rather than ACN, specifically to get the mplayer-jack-ambdec chain to work as expected (which I suspect is one of the more common use cases). Ambdec's functioning is completely unaffected by this, unless of course, you're depending on seeing Ambdec's inputs in ACN order in jack. Here's patch file against the current sources: http://www.ai.sri.com/ajh/ambisonics/ambdec-jack-fuma-order.patch Aaron On Fri, Nov 15, 2013 at 3:10 PM, Andy Furniss wrote: > Marc Lavallée wrote: > >> >> In my experience, the order of channels in jack are stable enough to >> use this simple channels remapping trick: >> >> mplayer -channels 4 -af channels=4:4:0:0:1:3:2:1:3:2 -ao >> jack:port=ambdec AJH_eight-positions.amb >> > > FWIW, while looking at mplayer code it occured to me that - > > 1. My suggestion in my last post to make mplayer sort by name is silly > and would be wrong for higher orders where channel number matters (I > can't reply to my own post because of the stupid way gmail works). > > 2. Rather than taking time to extend mplayer to take input names, though > useful, I could just use qjackctl patch bay. With that I can set up > connections how I want and handle all the variety of higher orders > (though I did notice an 8 channel limit in the mplayer code - easily > changed). > > So if I did need to use mplayer for many different types of .amb I would > just set up different mappings in patchbay, load my settings on starting > jack and then with recent (older doesn't have noconnect) mplayer do > something like - > > mplayer -channels 4 -ao jack:name=MP4:noconnect some-bformat.amb > > mplayer -channels 7 -ao jack:name=MP7:noconnect some-3rdhoriz.amb > > etc. MP4 and MP7 being names used in my patchbay config the right > connections will be made when mplayer starts. > > > > ___ > Sursound mailing list > Sursound@music.vt.edu > https://mail.music.vt.edu/mailman/listinfo/sursound > -- next part -- An HTML attachment was scrubbed... URL: <https://mail.music.vt.edu/mailman/private/sursound/attachments/20131116/76969c53/attachment.html> ___ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
Re: [Sursound] Linux ambdec b-format channel order
On Sat, Nov 16, 2013 at 11:38:09AM -0800, Aaron Heller wrote: > I encountered this a while back and modified my copy of Ambdec 0.5.1 to > register its inputs with jack in FuMa order rather than ACN, specifically > to get the mplayer-jack-ambdec chain to work as expected (which I suspect > is one of the more common use cases). Ambdec's functioning is completely > unaffected by this, unless of course, you're depending on seeing Ambdec's > inputs in ACN order in jack. Here's patch file against the current sources: > > http://www.ai.sri.com/ajh/ambisonics/ambdec-jack-fuma-order.patch While I understand the motivation for doing this, it's futile. Jack does not have any notion of the 'order' of an application's ports. If a Jack API call happens to list the them in the order they were created you are just being lucky. The only valid way (ATM) to determine any order is to interpret the port names. Patches to Jack have been submitted (not by me, but I'd have supported them) years ago to solve this problem, but they were rejected with the usual promise of a 'better' solution which so far has not materialised. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
Re: [Sursound] Linux ambdec b-format channel order
Hi Fons I would be happy to use a patched version of mplayer *and* a patched version of jackd; is the patch for jackd still available (and compatible with jackd2)? -- Marc Fons Adriaensen a écrit : > On Sat, Nov 16, 2013 at 11:38:09AM -0800, Aaron Heller wrote: > > > I encountered this a while back and modified my copy of Ambdec > > 0.5.1 to register its inputs with jack in FuMa order rather than > > ACN, specifically to get the mplayer-jack-ambdec chain to work as > > expected (which I suspect is one of the more common use cases). > > Ambdec's functioning is completely unaffected by this, unless of > > course, you're depending on seeing Ambdec's inputs in ACN order in > > jack. Here's patch file against the current sources: > > > > http://www.ai.sri.com/ajh/ambisonics/ambdec-jack-fuma-order.patch > > While I understand the motivation for doing this, it's futile. > > Jack does not have any notion of the 'order' of an application's > ports. If a Jack API call happens to list the them in the order > they were created you are just being lucky. > > The only valid way (ATM) to determine any order is to interpret > the port names. > > Patches to Jack have been submitted (not by me, but I'd have > supported them) years ago to solve this problem, but they were > rejected with the usual promise of a 'better' solution which so > far has not materialised. > > Ciao, > ___ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
Re: [Sursound] Ambisonic first approach
On Sat, Nov 16, 2013 at 05:12:32PM +0100, Jörn Nettingsmeier wrote: > you are right, i should have phrased that more precisely, the > connectors are actually fine, or at least not the biggest problem. > > the _cables_ are frightfully flimsy (which is a consequence of the > small size of the 6-pin miniXLR), and they are very inconvenient to > re-solder in-the-field, which i've been forced to do several times, > despite handling them with the utmost care. Exactly to the point. When I'm handling the Tetramic and its cables etc. myself I know these are delicate. No problem. When others get involved things change. Two years ago I was sharing a mic stand with the RAI (Italian public radio). The mic was 3m up, the four phantom adaptors on the floor between the stand's legs. No tension on the cables, I did take care of that. At one point, the RAI audio engineer decided to move his mic. Dragging the four PPAs and the cables attached to them behind it. It destroyed the Tetramic's rubber shock mount and the 10ft mini XLR cable. Of course the RAI engineer was very sorry. And of course I should have taped the PPAs to the mic stand. But this is not the kind of thing that should happen that easily with professional equipment. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
Re: [Sursound] Linux ambdec b-format channel order
On Sat, Nov 16, 2013 at 05:35:31PM -0500, Marc Lavallée wrote: > I would be happy to use a patched version of mplayer *and* a > patched version of jackd; is the patch for jackd still available (and > compatible with jackd2)? Don't know if they are still available. But if implemented in Jack they would still require applications to be aware of them. The solution with current Jack is that Mplayer should use the port *names* and match them against the channel order in the file it is playing. Or allow the user to specify the connections in some way. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
Re: [Sursound] Linux ambdec b-format channel order
I meant a patched ambdec... Also, A patched mplayer would be better, as you prescribe. Another limitation of mplayer is the number of output channels, which I think is limited to 8 (to be verified). -- Marc Fons Adriaensen a écrit : > On Sat, Nov 16, 2013 at 05:35:31PM -0500, Marc Lavallée wrote: > > > I would be happy to use a patched version of mplayer *and* a > > patched version of jackd; is the patch for jackd still available > > (and compatible with jackd2)? > > Don't know if they are still available. But if implemented in > Jack they would still require applications to be aware of them. > > The solution with current Jack is that Mplayer should use the > port *names* and match them against the channel order in the > file it is playing. Or allow the user to specify the connections > in some way. > > Ciao, > ___ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
