Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!snorkelwacker.mit.edu!ai-lab!mole.ai.mit.edu!ceej From: ceej@mole.ai.mit.edu (Chris Hillery) Newsgroups: comp.sys.amiga.audio Subject: Re: MED things Message-ID: <13840@life.ai.mit.edu> Date: 9 Mar 91 04:03:15 GMT References: <13748@life.ai.mit.edu> <45212@ut-emx.uucp> Sender: news@ai.mit.edu Organization: The Internet Lines: 150 In article <45212@ut-emx.uucp> greg@ccwf.cc.utexas.edu (Greg Harp) writes: >In article <13748@life.ai.mit.edu> ceej@.ai.mit.edu (Chris Hillery) writes: > >I am the post you mention here. I understand well the differences in features >between MED mods, 16-sample ST mods, and the newer ST/NT mods. I'm not trying >to save modules in MED's format and then load them into NT players. I'm saving >them using the ST-mod option on the save menu. Before anyone asks, let me >assure you that I am not doing anything in my music that is MED-specific. >All of the codes are ST/NT standard. > I wasn't assuming you tried to save a song as a MED modules and then wanted it to work in a NT-mod player (I'll give you THAT much credit... =). I WAS thinking that you tried to use MED-specific commands and then wanted them to work in a NT-mod player. That, obviously, won't work... However, since you say you didn't do so, I am confused. I've done several times, and just did again to be sure, exactly what you said, with no problems that I can recall; certainly it worked just dandily this time. I loaded in a song with only NT-type commands (and speeds, too; I'll assume you used the correct speeds) and saved it as an ST-mod. It played just fine in both Module Master, and in IntuiTracker. > What we have here is a direct statement by Tiejo >Kinnunen (the author of MED) that his program will save an ST/NT compatible >module, which I can then load into NoiseTracker or a compatible program. > >Well, I can tell you that not one of Intuitracker, Module Master, NoiseTracker, >ProTracker, or StarTrekker believes MED here. >... It's saving something having to do with the position and lengths >of samples incorrectly. > Again, I remain confused. I've had no real problems. I have heard songs that sound as though the sample-lengths are screwy, however, and it's possible that those songs were developed in MED and it messed them up. If so, that's a bona fide bug and will hopefully be cleared up. I guess my main question is really "So what?" I'm all for basically scrapping NoiseTracker format in favor of MED's anyway, simply as it appears more stable and certainly, incorporating as it does all of MED's more powerful features, is much more, well, powerful. More on that in a minute; but lemme get this next bit done: >>The other poster who couldn't get IFF-sounds to load: were these sounds be >>any chance saved out from NoiseTracker or SoundTracker? [...] >My major gripe here is that MED loads IFF samples and then ignores the >sampling rate. I know this to be true because I had a sample that was >_very_ out of tune with the others, so I loaded it up in a sample editor >(AudioMaster II, in case you think it's buggy, too) and changed the sampling >rate appropriately. I then reloaded the sample into MED and it was still >out of tune. I loaded the old (unmodified) copy of the same sample into >a different bank and compared them. They were exactly the same! This >sample was nearly a full step off key (but not quite) and when I loaded >both versions into MED I got the _same_ note. Loading them both into >AudioMaster produced _vastly_ different notes (the old version was still >nearly a full step off and the new one was correct). Simply playing the >sample from the command line (using 'sound') produced different notes and >displayed different sample rates. Why, then, does MED ignore this sampling >rate? It should be modifying the given rate appropriately to play different >notes, not using some set table of playback frequencies and ignoring any >specified rate given in the IFF file. > Here I KNOW exactly what the "problem" is, and sorry, it's you. There's a very good reason that MED ignores sample rates; it's supposed to. By definition (IFF 8SVX definition, I believe), middle-C (C-2 in MED) is to be played at 8363 samples/second, and all other notes are set rates directly related to that. I'm rather surpised that you, as an Amiga musician, didn't realize that. Let's consider why, from MED's standpoint. Over MED's nearly four-octave range for internal samples, it covers sample rates from 4000 sample/sec (approx; half of middle-C, anyway), which is nearly too low a rate to be of much use, to nearly 32000 samples/sec (also approx), which is considerably higher than the poor sound chip's top speed of around 28000 samples/sec. So, you see, MED covers nearly the Amiga's entire effective range of sample speeds. MED doesn't care what sample speeds are for the sake of computing speed and standardization; all Amiga music programs should be the same way. If you simply change the sample _Rate_ in Audio Master, it naturally won't affect what MED plays since you have changed the _number_ of samples or their values. This much should be apparent. Fortunately, MED (and no other program i'm familiar with, actually, another superior feature of MED) allows you to transpose individual samples (as well as tracks, blocks and the whole song); for instruments, simply go to the Sample frame (F3) and change the Transpose gadget. Granted this only works in half-step intervals (and this is a feature I would dearly love to see, fine-tune transposing of at least the whole song for use in live performance (listening, Teijo or Zap?)), but it is easy. Basically this means if you enter a C it'll actually play an F# (for instance) if you have the transpose set to 6. The alternative is to load the sample into Audio Master and actually re-sample the data to a different samplerate. This actually changes the samples and such, so it'll have the desired effect in MED. >>This poster also mentioned that he couldn't get NT-mods to load correctly. >>I don't know what it is about NT-mod format, but it seems to be seriously >>prone to odd flaws that make no difference to one program but totally be- >>wilder another. > >I can _certainly_ blame MED here. Look at the evidence. Everything else >seems to work correctly with true ST/NT compatible mods. MED doesn't. >Therefore, MED is buggy. Tiejo Kinnunen needs to sit down and figure out just >what he's done wrong. > I still can't 'cause, looking at my evidence, sometimes some programs can't load stuff. MED is NOT always the one that can't. However, it's possible that's it screwy. Well, again, I wish that we could forget about NT-mod format. It certainly has it quirks, as do the vast majority of the software programs which output in it. >I really like MED's editor, and, well, it's the only true multitasking ST/NT no, no, no... ^^^^^ >mod editor I've found. I have to give the author that. I'd really like to >keep using MED, but I want my music to be ST/NT compatible -- I'll have none >of this program-specific module format. > *shrug* why not? Remember, NT-module format was once a non-standard format specific to one program (remember SMUS?)... why not make way for a new one? And at any rate, MED is not designed to really be a NT-clone (more power to it), and has complete support for using its compositions in outside software as was the original point of SoundTracker; if there are some growing pains I'm not surprised nor concerned. At the least I don't think Noise- Tracker incompatibility, however slight, is a reason not to use MED. (While full working multitasking IS, most definitely; I often run many many things at once and can't afford to either shut them off or have a music program crash while they're going. And MED is more bug-free than a fair number of commercial products I have used.) >>Happy Tracking! > >Maybe someday... > >Greg >-- > Greg Harp |"How I wish, how I wish you were here. We're just two > |lost souls swimming in a fishbowl, year after year, >greg@ccwf.cc.utexas.edu|running over the same ground. What have we found? > s609@cs.utexas.edu |The same old fears. Wish you were here." - Pink Floyd Ceej aka Chris Hillery ceej@rpi.edu Newsgroups: comp.sys.amiga.audio Subject: Re: MED things Summary: Expires: References: <13748@life.ai.mit.edu> <45212@ut-emx.uucp> Sender: Followup-To: Distribution: Organization: The Internet Keywords: