emusonacid!

i love to burn but i'm telling you guys its all gone..i'm not tripping out, i don't drop hits anymore . its just gone, period. about 95% of my samples are in stereo. i've been using my rfx card, and i've had no problems. i really don't know what else to say......ez, i'm goin to smoke a and play with my problem free e4..lol...haha..just takin the piss guys..lates

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

fuck yeah, Razmo!!!

hey, can anybody help me quickly? i really want to install 4.7 but i cant get it on a floppy. it always says the file is a little too big. i tried with brand new floppies on pc and mac - and with various eos downloads. i also cant get eloader somewhere, but id prefer the floppy solution, as i heard eloader is not working on mac.
cheers

heiner

I've got a version that automatically extract itself to a floppy on the PC... will that be of any use?

i guess thats the one i have, but how can i extract it to a floppy as i downloaded it from elsewhere and brought it to a pc via cd.
i cant get into the net with my pc right now - and cant get the file on a floppy. can you mail me your pc file, that has already extracted itself to a floppy? (mail: heiner@basswerk.de)

hi everyone...

i am back to the civilisation and online again...
as soon as i get any time i am going to try with memory swapping...
how many guys can confirm problem of random panning solved?


d2k

and, all the best to everyone...

greenman wrote:hey, can anybody help me quickly? i really want to install 4.7 but i cant get it on a floppy. it always says the file is a little too big. i tried with brand new floppies on pc and mac - and with various eos downloads. i also cant get eloader somewhere, but id prefer the floppy solution, as i heard eloader is not working on mac.
cheers

heiner

i used 'eloader' successfully on the Mac. I needed to boot back to Mac OS 9.2.2, install 'Mac OS Runtime for Java 'MRJ' downloaded from Apple downloads then used the installed app to upload the new OS..worked perfectly from memory ;-0

I noticed the file is not on the downloads page so i took the liberty to upload it. ill PM Ezman now so it appears on the d/l page asap.

I'll bump again as we got a bit side tracked.

Can everybody who seems to have had their panning issue solved please post up what make/size/specs of the ram that they are using for

(1) sample memory
(2) the other type of memory that seemed to be causing the problem.

Thanks in advance.

re rfx: outbursts

switching my rfx card from an e6400ultra with 4.61 to an e4xtultra with 4.7
brought me the outburst problems. i had been using that rfx card for 12 months before without problems.

they mainly come through on bus 6, even if that bus is not routed to an output. after having used that bus, they are also on bus 4,5 and 7 but disappear after a while. the outbursts go out even through analog and adat out-expansions of the rfx. exchanging the little dram of the e4xt to a 64 meg piece that was indicated as 8mb didnt help. going back to 4.61 on the ultra also didnt help.

putting the card with all the extensions back to my e6400 ultra - all problems gone.

little disappointed about 4.7 anyway, as the wet/dry settings still changed when effects were changed in bus routing - not to 100% but to something else not much better

A small addition.

I was puzzled as I had a bank that was made entirely of mono samples however, it was bouncing about terribly. Closer inspection revealed that I was using chorus ('Voice Modifier' page) on some of the voices. This automaticaly uses up 2 voice slots as mono samples are converted to stereo. This would allow Razmos voice allocation problem to take place.

Andrew

greenman wrote:switching my rfx card from an e6400ultra with 4.61 to an e4xtultra with 4.7
brought me the outburst problems. i had been using that rfx card for 12 months before without problems.

yep, it's apparently a 4.7 only bug, as opposed to the random panning bug which is apparently in any EOS version, both bugs tied to RFX.

greenman wrote:exchanging the little dram of the e4xt to a 64 meg piece that was indicated as 8mb didnt help.

well, maybe you read it wrong, but the Preset RAM (aka D-ram, although it says D-ram next to your sample RAM on the motherboard too) can only take a maximum of 16MB, so who knows what a huge 64MB SIMM would do. i would try it again if possible w/ a 8 or 16MB SIMM. we have one person, namely cm_locuss, who has had every single issue of his fixed by changing this RAM. read his post here:
viewtopic.php?t=346&postdays=0&postorder=asc&start=30

we're still in the process of finding out if this fix works for anyone besides cm_locuss though. what happened to everyone who had these problems? has nobody else tried it? I know Division2000 is close to getting the right SIMM and will post his findings soon.

of course, Razmo has also seemed to find the exact cause of the "random panning" bug (and also has shown how it could be tied to outbursts as well) but if changing this RAM somehow fixes it for everyone, we're psyched.

for me, i bought my E4 just months ago, i haven't even made presets w/ it till late last month, so i can't say i have bugs fixed when i didn't have any to start with.

i did, however, share the problem cm_locuss had of super bad freezing problems. myself and Klaseed discovered this Preset RAM swap to fix the freezing. then lo and behold, cm_locuss says EVERYTHING got fixed for him...he had presets apparently w/ random panning AND outbursts that are all now solved, not to mention his crashing/freezing problems are gone like are mine. now that i'm into my E4 AND RUNNING 4.7!, i can say i haven't experienced any bugs yet. (knock on wood)

so maybe since me and cm_locuss we're the only one's who had this rare "freezing/crashing w/ RFX and 4.6 or 4.7" problem, maybe this RAM swap will only fix the bugs for us. i dunno? we'll never know till someone else tries!!

it would be nice to verify this so we know if we need to continue to push EMU for a new EOS version. although, of course, it would be nice either way.

greenman wrote:going back to 4.61 on the ultra also didnt help.

well that's odd, i've heard outbursts is only a 4.7 bug:
http://www.basscadets.co.uk/emu/EOS470.htm

Hi again!

I hardly believe that you will fix all bugs by just changing a preset ram block. Especially the Panning bug I don't think will disappear. I'm 99.9% certain, that the panning is software oriented. As the panning bug disappears after one full cycling of the voice allocation (look in ChanVol page), this should elliminate any hardware prob. (and be happy for that!). I've been wondering, since I've got "only" 64 voces in my Ultra, if anyone with 128 voices have the same problem? The allocation routine would have to be different with this option, so maybe this works right? Maybe some of you should try and perform the same routine I did to reproduce the PanBug effect, so that we can get more info on this. I'm an assembly coder myself, so I know how weird bugs can act, and the PanBug surely looks like a soft bug to me. I bet, that the code for allocation with an RFX is a different set of code, that the one without RFX. This explains why the problem goes away when removing the RFX. The ultra says: "hey! no RFX, we'll execute this allocation code then...", or it says: "RFX is here! We'll execute that allocation code instead", and THAT code is buggy! . I think EMU have made some serious code changes to make RFX possible in an Ultra sampler. I recall having read, that even the Filter code has been reproduced because the old code was unflexible. Who knows how many changes they have made for the RFX? But lets not forget, that EMU has now stated that they are working on it, so it will most certainly be fixed at some point. Maybe we will even see some new FX also, since the comming Emulator X is also using the R-Chip. New effects for the Emulator X should be easily portable to the Ultra I guess (fingers crossed).

razmo wrote:I hardly believe that you will fix all bugs by just changing a preset ram block. Especially the Panning bug I don't think will disappear.

right, of course it doesn't seem logical but it has worked for one person. isn't it at least worth it for someone else to try so then we know?

razmo wrote:But lets not forget, that EMU has now stated that they are working on it, so it will most certainly be fixed at some point.

hmmm, when did they say that? if it's something they sent you, you should post it here, if you haven't already. i kinda have the feeling that they're just trying to brush us off for now, and may or may not have real intentions of updating EOS.

(from an EMU developer):

...Yes, Razmo has gotten some valid insight into the problem, but unfortunately there is not much new information there for us.

We also recognized sometime early on (like 18 months ago, when people first started posting banks we could use to reproduce the problem) that the "random panning" effect that people heard was really a channel reallocation/ripoff problem of some sort. The effect clearly occurred when reusing a mono channel that had previously been allocated as one half of a stereo pair.

It was also apparent to us that this was a timing issue of some sort, likely a race condition due to activities that were occurring in different execution threads of the operating system that, combined together, are responsible for initiating new note ons. The hardware initialization required for starting a new note is VERY complex and obviously has to occur so as to minimize "MIDI delay", so there are a lot of very arcane optimizations going on.

One thing that's new here is that the problem APPEARS to be dependent on which DRAM he is using. This could be the case if there is a speed difference in the RAM that the CPU can take advantage of, leading to a speed-up or slow-down in execution speed of the OS. However, to the best of my knowledge, the Motorola Coldfire CPU used in Ultra machines does not do any autospeed sensing of RAMs, but is initialized in software to a specific number of wait states and runs the memory bus at exactly that rate. But I will double-check this to make sure, as it is the most intriguing new symptom.

However, the somewhat random allocation order razmo is seeing on the channel volumes page is normal. EOS has its own rather arcane, and needless to say proprietary, criteria for choosing which hardware voice channels to allocate to new notes.