emusonacid! legacy

drayon wrote:I have emails archived from that list dated back to the 10th month 02. Is it likely you mails were posted in that time? If so let me know the address u used to post them and ill search my archive.

I'm not sure of what email address I was using at the time, it could have been one of many. I'm sure the posts had the words "Ping Pong" in the title, it wouldn't be too hard to find as there were a large amount of posts on the subjuect.

i don't know if you guys have tried to replace the d-ram...but ever since i replaced my 8 mb with a 16mb chip i had and installed 4.7 i've had zero, let me repeat that..ZERO problems. i've been in the studio about 5 or 6 times since i've done this. each session i've spent anywhere from 5-12 hours in there with none of the problems i had before......just giving you guys a heads up ...ez

That good news cm. I'll be checking it out as soon as possible, hopefully tomorrow. I've got 80 meg of sample ram (64 + 16 which shows up as 72), can I use the 16 meg stick. I aslo wonder as it's the 16meg I got with the e6400 as default, is this ram dodgy too?

Hi folks! :O)

I've been troubled quite often with this random panning issue in my E6400 Ultra too. I've witnessed it in a rather subtle way actually. As I've been using my sampler mostly for drums, I've often been able to hear short "clicks" in the beginning of drumsamples (especially bright snare sounds). It seems that it bounce between left and right, and is rather annoying.

Then I read the DRAM thing, and thought: well... why not give it a try. I swapped the 8MB with a spare 16MB one, and GOD DAMNED IF IT'S NOT ALL GONE NOW! :O) ... The DRAM swap certainly worked for me, so I'm off to install EOS 4.7 again. I'll let you know if anything else comes up.

Regards, Jess D. Skov-Nielsen (Razmo)
Denmark.

I forgot to mention, that I've got a VERY early E6400 (the ones with the puny insufficient power supply). On top of that I've also got the DWAM, RFX-ADAT and RFX option along with 128MB RAM.

I guess the only problem I've got now is, that my supply is driving on it's limits! ... I've had it repaired twice after overloading, and even had my 20GB HD fried once (it litterally burned a f...... hole in a HD chip!!!!). I'll never forget that smell!!!

But let's not get too exited about the newly discovered solution (alright, a tad little bit then... ;O) ... but remember that there are still some things we'd like to have fixed, like the slow disk-drive because of leftover FAT32 code etc. Not to mention that it would be VERY handy to get a complete MIDI implementation done so that we can take full use of our RFX/Sampler.

Anyone know how big a HD EOS 4.7 can handle?

Regards, Jess D. Skov-Nielsen (Razmo)
Denmark

I've got some bad news. I tried using the 16 meg I had spare with the emu and I still get beats panning about. I've got an especially evil bank which seems to bounce all over place and there was absolutely no difference with the larger ram.

I am still hopeful it is a ram problem as this 16 meg stick is official emu ram that was installed when I got my e6400 ultra. I suppose we need a list of the makes of ram that do not cause the pan effect.

I would be most grateful if people could post up the make and serial of the ram they are using (including sample ram too).

Hi again!

Installed 4.7 now. I'm now getting random panning, but I believe It's not an issue with 4.7 though because I tried something different this time . On the contrary, I'm able to reproduce the random panning effect, and I'm not using any specific banks at all! Just a freshly cleared bank.

I think the problem lies with the voice allocation somehow. Here is how I reproduce the "effect":

I've got two different wav files loaded on my PC, and are sending them to the sampler via SMDI. One sample is a mono file, the other a stereo file.
If I first dump the mono file to sample 1, and set up a preset to play with this sample there is no problem. Then I dump the stereo file onto the same sample nr. 1 and no problems there either, but when I then dump the first (mono) sample back on location 1 again, I get random panning effect!!! ... Everytime the sampler is playing a mono sample after having played a stereo one, this happens on my sampler! ... sometimes it will wait a few seconds before the random panning sets in, at other times it does it right away after dumping the mono sample again. One thing to notice is, that the random panning effect disappears again after a little while, and everything goes back to normal.

I now understand why I've not witnessed this effect so much, since my drumsamples are mainly mono files. Playing these gives no way for the random panning effect since all are mono. Now that I look back, I admit that the few times this happened for me was in fact when I had a bank that had both mono and stereo sample drums in it!

Perhaps someone out there should try and reproduce the thing too, because then we will have a better way of helping EMU solve the problem. A reproducable bug is a lot easier to correct!

Regards, Jess D. Skov-Nielsen.
Denmark

Ok guys! ... I'm 99% sure I found the reason for the panning bug!!!!!!!!!!!!!!!!!!!!!!!!!!! :O)

Try the thing I mentioned above, and then enter the ChannelVolume utillity in the MASTER section of the sampler!!! look at those bars! they act like crazy!!! ... If you think about it, when a stereo sample is played, it takes TWO voices as can be seen. These voices get assigned to left and right side when you play a stereo sound. If these allocations are not reset in the correct way, mono samples may take on the assignment of previously played notes. This explains why the effect sets in at different times, and why it only happens when mono and stereo samples are used at the same time!!! ... this MUST be it guys!!! ... just look how the voices sometimes bounce wildly in the display! ... normal allocation would have them cycle nicely after eachother.

I guess We'll have to tell this to EMU right away, so they can get on with the bug fixing!

There is more!!!!

If you dump a file through SMDI, you will notice that the whole ChanVol page gets cleared. If you slowly press ONE key repeatedly, you will notice, that at a certain point (two points to be exact), the allocation jumps to the first four allocation slots. It allocates two at a time if you dumped a stereo sample to play with. Every slot is allocated left and right to properly play a stereo sample. If you then dump a mono file and start pressing one key repeatetly, you'll discover, that the panning effect change side from left to right, and right to left... why? because the former stereo playing allocated the slots that way! they have not been cleared! ... Also notice, that when the mono file has been played through all slots, the effect disappears!!! the slots has been correctly allocated!!!!!

That's it guys!!!! :O) ... problem solved!!!!!!!!!!!!!!!!!!!!!!
How come EMU could not even figure this out! ... sigh!!!! ;O)

Pardon me again, but I was wondering about something...
Why does a stereo voice take two slots? Have the Ultra's not only
allocated two voices for a sound, if you utilized the Software Chorus feature?. Is this an "unmentioned side-effect" of installing an RFX card?

With the bug figured out now, I think you can do a work around it in the following ways:

1. Use only mono, or stereo samples on a project.
2. Use both mono and stereo samples, but make presets with mono samples into ones that utilize the software chorus feature, and make the stereo width setting 0% (being a bad tradeoff in polyphony)
3. Convert all mono samples used into stereo samples

I'm not certain what can cause those loud outbursts that some of you have experienced, but maybe they are related to the sudden "jumps" in the voice allocation cycle? ... EMU!?

Nice bit of investigation Razmo. This proves the point made in the posts on the emusaic list, it's a phase problem - who said hardware samplers dont suffer latency problems

So it looks like when the voices are not in the right order/sync (in the ChannelVolume screen) they play at slightly different timings creating a pan effect. I wonder if the RFX adds extra latency as the signal has a further to go. There were a few people who noticed this problem long before the RFX existed however the problem was very very slight - it seems that the RFX is amplifying the problem. I wonder if dodgy ram magnifies these problems even more. If only I had the diagnostic tools to accurately check timings etc

Hi!

Really, I don't think the panning is a phase problem. It's rather a voice allocation problem. If you look at the allocations done while playing in the ChanVol page, you will notice, that the problem stops once the cycling has passed through all slots once. This hints me, that it's an allocation problem. If we say that each voice slot has an internal panning parameter, this should be initialized when the slot is taken into use. If the sample to use is a mono sample, it should be panned in the middle, if a stereo one, it should be panned either left or right depending on the stereo channel using the slot. If this allocation gets screwed up, things might definitely end up as random panning effects, which is the case here. I think that maybe the "jumps" in the cycle is the cause of these faulty allocations. Some pointers in the slot-allocation routines must be out of sync when this happens. Only EMU will know about this for sure, but I'm certain it will be an easily fixed bug actually.

wow, good job Razmo...please forward your information to EMU, although sometimes they seem not to care (at least they've treated me that way before).

now i'm wondering a couple things:

1. why did CM_LOCUSS's freezing/randompanning/outbursts problems all get solved w/ changing the Preset RAM?? maybe homeboy is just smoking something (well, i'm sure he's smokin SOMETHING ) and his random panning issue is somehow now alluding him or has been fixed inadvertently another way??? also, i wouldn't be so sure it's because he used a 16MB stick as opposed to a 8MB, for anyone else out there trying it.
CM-- do you use a mix of stereo and mono samples?

2. what about outbursts? can someone who has that problem see if either of these two fixes (the Preset RAM swap or the exlusive use of mono or stereo samples) work in fixing that one?

3. OH, and Illinformed: I would definitely try a non-EMU RAM stick instead of that one you have. and again, i doubt the size matters (at least in this case , so try an 8MB if you have it too...it doesn't matter where you get it as long as it's a normal 72Pin SIMM i believe.

Hi everyone!

Just mailed my discoveries to EMU using the adress Dave wrote would be the most useful (fastest) one.

What I wrote you can read here:

------------------------------
Hi EMU! :O)

I made a few experiments, trying to reproduce the Random Panning bug in your EOS, and guess what! ... I found a way! :O)
It is a voice allocation bug I assume, and if you follow my explanation below, you should be able to locate the bug and fix it.

Do the following:

1. Connect an Ultra sampler to a PC via SCSI
2. Load two samples on the PC wave-editor (soundforge/wavelab etc.). One must be a mono sample, the other a stereo sample.
3. Clear the sampler's bank in the Master page.
4. Edit preset 0 so that it uses sample no. 1, and make sure you can play MIDI notes to the sampler live.
5. Now dump the stereo sample to sample number 1
6. Enter the ChanVol page in master/ultil
7. Play a key on the keyboard, and keep doing that repeatedly.
8. Notice that the cycling of the allocated voices suddenly jump to the first four slots at specific times in the cycle!!!! This seems unnatural!!!
9. Now dump the mono sample to the same sample no. which is 1
10. Play the keyboard repeatedly again.
11. Notice how the sound swap sides while playing!? ... That's the Random Panning bug in action!!!
12. Keep playing and notice, that when the cycling of the allocation has passed once, the bug is gone as the "pan alloc. buffers" has now been
correctly assigned from the last cycling.

Somehow the allocation slots that was previously set to left/right panning to play the stereo sample correctly is STILL evident when a new
mono sample is to use the slot later in the allocation cycle. It seems that mono samples using the slots do not properly initialize the panning
when taking a slot in use. The reason could be many, but I'll leave you to figure that out! ... I hardly believe you'd let me into the deeper
programming secrets of the EOS to fix this I suppose! ;O)

That's it EMU! :O) ... now I spared you the time of finding the bug, now fix it for us please!

Regards, Jess D. Skov-Nielsen
Denmark.