I just installed an "intelligent" Cross-Fader plugin for winamp. I really like it! So, how could I help proposing something like that for I the Great Empeg? Basically, what would you think of a Cross-fader effect between songs when listening, for example, in random order? It could be a simple "play mode" to be selected as an item of the "shuffle" menu, which in its turn may be renamed to something like "play mode". (maybe it's already like that in 2.0?). If anybody wants to try such a thing on winamp, it is called
SqrSoft_Advanced_Crossfading_Output.exe
and it's here .
Very simply, while song one fades out, song two fades in, and they merge perfectly with avery very nice effect.

Taym
_________________________
MK II BLUE/RED 12GB #923

Yeah, I really love this plugin too!! I've used it several times on parties. Just my laptop, a mixing panel and some HK Audio speakers were all the things needed. Stop, skip, rewind, fast forward also cross fade very nicel.

­­______________
Edwin de Vaan

Here's a previous post on cross fading

#695-Mk2/8 colors-12Gig w/Tuner- awaits v2.x & Voice Recog.

Ok, that thread seems to end up talking about the voladj plugin. If I am not mistaken nobody has written any crossfader, yet. However, I'd like to see it implemented in the v.2.0 official empeg sw, if possible. That's way too a nice feature, It really increases the pleasure of listening to music, in my opinion.

Taym
_________________________
MK II BLUE/RED 12GB #923

OK how about this thread then.

#695-Mk2/8 colors-12Gig w/Tuner- awaits v2.x & Voice Recog.

.......or this discussion perhaps.

#695-Mk2/8 colors-12Gig w/Tuner- awaits v2.x & Voice Recog.

Thanks for the links to the previous threads. So, looking at the 2.0, it seems it will not be there, either. Or is it one of the feature not mentioned? :)

Taym
_________________________
MK II BLUE/RED 12GB #923

OK, sorry for the links, I also would like to see if someone could create a fader of some sort whether it's in a 2.x version or as an add-on..

#695-Mk2/8 colors-12Gig w/Tuner- awaits v2.x & Voice Recog.

I love the plug-in and think this plug in would be great on the empeg! Maybe we can contact the author of it and see if he has any interest in making a version compatible with the empeg?

32GB Mk. II in a WRX
Detroit, MI USA
www.PfeifferBeer.com

Talk about something to wow your friends and something that a HU CD/Cass. player couldn't. I already get them sometimes when I pause the radio using the pause button and tell them I can even pause a station sort of like a Tivo.

#695-Mk2/8 colors-12Gig w/Tuner- awaits v2.x & Voice Recog.

No, crossfading between tracks is not going to be in v2.0. We wanted it to be, but other things became more important. Maybe it'll appear later in v2.x, but I'm not promising anything.


-- roger

I realize it isn't a priority, but thanks for keeping it in mind!

32GB Mk. II in a WRX
Detroit, MI USA
www.PfeifferBeer.com

Hmm... I'm totally hypothesizing here but it seems to me that now that the product is EOL, this feature, which has been requested many times, might actually happen. Since automatic crossfading doesn't really exist in other commercial audio products (does it???) it wouldn't be a feature that would sell many Empegs/RioCars. Windows Media, WAV, improved tuner, bookmarking, new shuffle modes are all big features that had commercial/marketing impact, so I think that's why they were worked on first.

So the way I'm thinking, now that the product is EOL, I can see this being worked on as a "background task" if the developers want to sneak something cool in. Obviously for 2.0, WMV and WAV support were priorities, as were improved tuner support, the bookmarking, shuffle modes, etc. What other major features could they need to put in? Okay voice recognition should be a priority. then what? I think this is a good candidate to be one of the first major features to make its way into a post-2.0 build. The theoretical discussion of how it would work has already happened in another thread on this BBS, and I think the developers even chimed in at one point. So let's hope this gets close to the top of the list as the 2.0 baseline stabilizes and the developers look for something new and fun to throw into the player's bag of tricks.

-Tony
MkII #554

Nah, that's not the way to go. A plugin architecture will allow other people to do these interesting projects--that's really where they should spend the time. Now that v2.0's nearly out...here's hoping.

Fly me to the moon...

Various Audio Plug-Ins that would rock:

1. Cross fade
2. Compression
3. Noise Cancellation via Mic Input (would cancel out road noise)
4. Reverb Settings (I actually hate these)
5. Funky effects for dance music?

32GB Mk. II in a WRX
Detroit, MI USA
www.PfeifferBeer.com

6. Volume adjustment via Mic input (more outside noise == more volume)

-Mike

Yeah but a plugin architecture adds no value in and of itself. No features are added, though the door is left open for features to be added by 3rd party developers.

The dev team has not shown much interest in implementing a plugin architecture, it's rather complicated to do. The 2.0 redesign doesn't include this plugin architecture, and I doubt they'd do another re-design to accomodate this. I would personally LOVE it and would probably try to develop some fun audio and vis plugins with it, but it didn't seem that was the direction they wanted to go. Any Empeg developers who want to chime in on this feel free. Actually, fix v2.0 and THEN chime in. :)

I defintely lobbied on this board for the plugin architecture but why would they do it now if they didn't do it when they went to the drawing board for an entirely new design?

-Tony
MkII #554

Well, since empeg sw development is continuing, and since that is due to its deployment in the future secret product(s), I think it would make sense for empeg ppl as well to implement a plug in architecture, which would boost third party partecipation to the success of the product(s) themselves, making everybody happy. Winamp is a remarcable example of how powerful a plugin architecture is in creating a successful community around a piece of software, and how that makes the sw itself successful. I would strongly recommend empeg team to go on the plug-in architecture path, if they're interested in one of their fan's opinion .
Just wanted to add my voice to your lobbying.

Taym
_________________________
MK II BLUE/RED 12GB #923

Exactly! How cool would it be for a 3rd-party development like Voladj to make it into another Sonic|Blue product? I imagine RJLov would be more flattered than insulted if SB used his code in the Rio Receiver, for example. If they open the architecture for plugins, they may indeed make money off of it (ok, maybe not lots of money, but new features are still cool enough to sell units, no matter who codes them).
Jason

_~= Dearing =~_
"WAY too happy about having #99."

If dynamic range compression appeared in any of the empeg team's products, I think that they'd probably use an algorithm of their own rather than Richard's code.

Don't get me wrong, his code is great, it's just that there's probably more efficient places to put the code than shoehorning it into the kernel. It'd probably be better if it were in the player software.

___________
Tony Fabris

Hi Tony

Don't get me wrong, his code is great, it's just that there's probably more efficient places to put the code than shoehorning it into the kernel. It'd probably be better if it were in the player software.

That is exactly where the plugin architecture would come in handy: The code could be moved from the kernel to the player (a plugin module for the player).

cu,
sven



proud MkII owner (12GB blue/green/smoked, was #080000113 is #090001010)

Yeah.

_~= Dearing =~_
"WAY too happy about having #99."

uh huh

ok

yep.

_~= Dearing =~_
"WAY too happy about having #99."

We already have a plugin architecture; it's just compile-time not run-time. There are problems with run-time plugins (eg .so's) which hinder us from adding such support - mainly memory use due to symbol tables.

The reason why it hasn't appeared is due to a couple of factors:

1. We're not going to cripple the products by adding a plugin interface (ie, we won't add it if we can't find a way to do it without sacrificing the "normal user" experience - and that includes having to reduce caching space)

2. We're unlikely to do it without a "proper" way to manage plug-ins, eg emplode control. Without this, the number of plugin users would probably only be about 20 people and wouldn't justify the work involved.

Plugins are nice in winamp, etc, but they don't operate under the same restrictions as we do. If we can add them neatly & cleanly, we will do so. This is not saying that it'll never happen, but it takes programmer time, and there are much higher priority tasks to complete first.

Hugo

In reply to:

---

We already have a plugin architecture; it's just compile-time not run-time. There are problems with run-time plugins (eg .so's) which hinder us from adding such support - mainly memory use due to symbol tables.

---

/me wonders...

Perhaps a halfway compromise could eliminate the symbols by linking at install time? There'd have to be a link editor on disk (unless this stuff was done it the upgrade host) and enough of a compiler back-end to write an object file (*.o) containing the array of plugin descriptors (one entry per module), but no extra memory overhead at run-time.

That would eliminate the need to do run-time loading of modules - unless we really expect to add and remove plugins without restarting the player...

--
Toby Speight - 040103385

I just wanted to cheer for empeg ver. 3.0!

wooooohoooooo!!! CHEER!!! life is good!

Regarding an older post, how about a feature that automatically adjusts the volume to counteract road and engine noise at higher speeds? GM has implemented this in many of its vehicles.

It might be possible to build an MCU-based solution that reads ambient noise levels (digitized), and vehicle speed (OBD/etc interfacing is probably non-trivial) and have it send vol-up or vol-down commands via the serial port. The one potential problem is that there's no easy way to contain "runaway" adjustments, although I suppose the MCU firmware could also sample the outgoing audio stream and see if the RMS signal level is "too high" (and force some limits that way). And this scheme of course assumes normalized volume levels for all tracks (good #@$!ing luck!), although even that might be do-able if the MCU keeps track of the average output level, and slowly increases volume for consistently "quiet" playback. But what happens when a loud track starts after a quiet one?

On another note, notwithstanding that player-supported noise cancelling would kick ass, isn't it actually something better suited to a separate device wedged between player output and amp (or pre-amp) input? A small box that samples the noise "out there", inverts, and mixes into the live stream (all analog) seems like a realistic possibility. Then again, I didn't go to school for EE...

Bear in mind, I'm still an utter novice at the moment, having owned my first player for just a week. But both hardware and software hackage are of keen interest to me.

Note that you're responding to a thread in which the most recent post is from 2003.

Quote:
It might be possible to build an MCU-based solution that reads ambient noise levels (digitized), and vehicle speed (OBD/etc interfacing is probably non-trivial) and have it send vol-up or vol-down commands via the serial port.

When you're at the point of making an external box... then.... why bother with serial port at all? Just have two pair of RCA ins and outs and attenuate those. Then you've built a box that will work with any stereo, not just the empeg. And it would work more reliably, and it would be simpler to build.

I've discussed this in other threads, possibly ones more recent than this 2003 thread. I think in one, I even drew a diagram of the box in question, asking if anyone knew how to build the necessary electronics.

Quote:
A small box that samples the noise "out there", inverts, and mixes into the live stream (all analog) seems like a realistic possibility. Then again, I didn't go to school for EE...

Yeah. Exactly.

Why hasn't anyone built one of these yet? Wouldn't it make a mint?

Quote:
The one potential problem is that there's no easy way to contain "runaway" adjustments, although I suppose the MCU firmware could also sample the outgoing audio stream and see if the RMS signal level is "too high"

Naw. You just make sure that the noise sampling microphone input is located outside the cabin of the car. Stick it in a wheel well or under the back bumper or something. That way it picks up road noise instead of music sound. Very simple.

You just make sure that the noise sampling microphone input is located outside the cabin of the car. Stick it in a wheel well or under the back bumper or something. That way it picks up road noise instead of music sound.

Ummm.... no.

It will be picking up the ambient noise in the immediate location of the microphone, which will bear little relationship to the noise inside the cabin of the car.

The noise inside the car comes primarily from wind passing over the various external protuberances of the car, from the tires contacting the road, and to a lesser extent from mechanical sounds made by the car itself. These noises enter the cabin of the car after being "processed" by the material of the car itself, that is, the sound from the tires is conducted through the wheels, suspension, and body of the car until it resonates inside the car. A similar process occurs with the wind noise. In both cases, the "quality" of the sound (frequency, intensity, etc.) outside the car is not the same as what you hear inside the car.

If all you want is volume adjustment... well, maybe. But it would probably be easier to tap into the car's OBD system to get the verhicle speed, or, for about $10 you can buy a magnet and a sensor switch (used on bicycle computers) and do your own independent measurement of wheel speed.

I don't think noise cancelling would even be possible without losing a lot of quality along the way. If the microphone were located outside the cabin, it would not be telling the proposed box the proper sounds to cancel, and if it were located inside the cabin, it would be "hearing" sound from the stereo and cancelling that as well as cancelling the noise. Even if you fed the signal from the stereo directly into the box and told it not to cancel any of that, some of the stereo frequencies would coincide with road noise frequencies and get cancelled anyway.

Noise cancelling works with headphones, where there is no "competition" between internal and extrernal sound. I don't see it working in a shared acoustic environment.

But then, my ignorance of such matters is only exceeded by my willingness to expostulate on them, so who knows?

tanstaafl.

I don't think you'd get the results you desire. To cancel the sound that you hear you'd have to grab the sound that is actually hitting your ear. If you playback the inverse of any other sound there is a chance ( I think a guarantee? ) that it will cancel some sounds but you will hear all of the other sounds that you aren't hearing that it is trying to cancel. I think that will just amplify the problem.

In other words : The recorded sound of the tires from the wheel well will differ from the sound that you hear in the driver's seat. You won't be canceling the sound you hear.

He's just talking about raising the volume, not cancelling noise.

Ahh. Word, then.