Support
Looper's Delight
|
Support |
|
|
> Ehm.. I fail to see how you'd have feedback problems with a sealed IEM? > Of cause, you may be talking about feedback generated elsewhere, being > fed to your IEM.. You're right of course wrt an application where you're performing solo or where you're controlling both the monitor mix and all the other open mics onstage. Have had several bad experiences with a sound man that only knew he 'should' have a compressor on the vocals but had no idea how to actually use it. Big feedback problems until we insisted he just pull it out of the rack . We were using regular stage monitors at the time. > Please explain the use of an expander here? My understanding of an expander is vague, but my thought was to make sure there was always sufficient level without permitting the compressor/limiter to boost the level. As you say -this probably could be achieved with just a 2-stage compressor. Dan Ash White Plains, NY > Subject: > Re: Canford Headphone Limiter (In Ear Monitoring revisited) > From: > van Sinn <vansinn@post.cybercity.dk> > Date: > Mon, 05 May 2008 18:46:22 +0200 > > To: > Loopers-Delight@loopers-delight.com > > > Dan Ash wrote: >> >> I'm another skeptic of in-ear monitors - so I don't speak from >> experience here... I would point out that compressors in general, if >> improperly used, are prime feedback offenders. > > Ehm.. I fail to see how you'd have feedback problems with a sealed IEM? > Of cause, you may be talking about feedback generated elsewhere, being > fed to your IEM.. > >> I don't care for headphones much either, but they've got to be much >> more easily removed in the event of feedback. >> >> Maybe a 2-stage expander->limiter would provide a predictable level >> in an in-ear system. > > Please explain the use of an expander here? I's have no problems with > a 2-stage system comprised of a low-ratio soft-knee limiter plus a > hard limiter to cut the really damaging tops really fast. > > And I can understand Buzap's worries for picked-up interfEARenses > *post* a limiter. Makes sense to me, hense, I too would want it as > part of my reciever package - *after* the actual reciever.