12 users online: Bullymario, DarkennyTheBlob, DasFueller, Lane, mio, SFan, smwln, SolveForX, SubconsciousEye, VecchiaZim, YouFailMe, Zoreo - Guests: 74 - Bots: 209 Users: 55,720 (2,332 active)Latest user: taste1122Not logged in.
Posts by musicalman
 musicalman's Profile - Posts by musicalman
 Pages: 1 2 3 4 … 5–14567891011121314 … 15 16
Wow... I now see what you were talking about. I just looked at the mml. It took me about 20 minutes of study of one line alone but I eventually figured out what is going on. It indeed uses gain fades which I had completely forgotten about, until I figured out how they work and then vaguely remembered reading about them on some article about the SPC. I'll explain for the benefit of those who, like me, didn't see it.

Basically when you set gain,, either with \$ed \$80 or in an instrument, the gain value can have several meanings depending on what range it's in. If the gain is set from \$00 to \$7f it is treated as a direct gain value i.e. \$00 is silent, \$7f is full. If it is set from \$80 to \$ff a gain fade is applied, which fades the current gain to full or silence, depending on whether you are using an increase or decrease fade.

Going from \$80 to \$9f uses the first decrease fade type, not sure the shapes of the fades right now, but it seems to be the most abrupt of the two. As you probably guessed, the higher the number, the faster the fade. Starting at \$a0 switches to the other decrease type which is more gradual. Its speed goes up to \$bf. The pattern continues for the increase fade types. I hope this make-shift explanation makes some sort of sense.

To illustrate how a sforzando might work, I could do the following. This isn't optimized, it just shows how you might set it up. Remote codes would make this more practical.

Code
```#amk 2
t45 ?

#0 l4 @4
\$ed \$19 \$20 c ;initial accent and diminuendo
\$ed \$80 \$c7 ^ ;gain fade for the swell
\$ed \$80 \$bb ^2 ;another gain fade for release, though straight-up ADSR probably could've worked too
```

Hope this helps somebody.

--------------------
Make more of less, that way you won't make less of more!
Thanks for that link. Most of what I know is from occasional reading and experimentation. Nothing hard and concrete.

Before I knew about gain fades I used ADSR for releasing so I know it works, though haven't tested it. When I did it, nothing had to be rekeyed. I haven't tested it here though. When I used ADSR for releases, only the release portion of that envelope would take effect, which I think makes sense. I suspect using a gain fade for a release is more practical though. I'll study your example in a bit,.

--------------------
Make more of less, that way you won't make less of more!
About your first question. Samples are not assigned to channels. They are assigned to custom instruments. As you probably know, putting @0 through @29 on a channel uses SMW instruments. To access custom ones, use @30 and above. They will work on any channel so long as you haven't messed anything up in the setup process. Your above setup looks fine so using @30, @31, @32 etc. should already work.

Regarding your second question I don't really know what to advise. If you're still having trouble with either question I can take a look at a port in progress and see if I can figure out what's wrong.

--------------------
Make more of less, that way you won't make less of more!
I've been wondering about these things too. I've never taken a lot of FM samples for ports, but I've thought about it.

To get FM samples, you could try to find a converter that can take fm patches from fm music files like Genesis for example, and convert them to patches for fm VST plug-ins. I'm sure some do exist as I remember reading about such a vst and converter once. But I can't remember what or where it was. But if you do find something that works, you can then load these patches, take a sample of each, and convert that sample to BRR. That's only handy if you're like me and you'd actually want to use those FM synths as instruments outside of a VGM context. If you just want samples for the Snes, a probably? more intuitive way is to just sample the sound you want in-game. Now that I think about it, that might be a better idea.

Most vgm players have muting channel capabilities so you could solo the channel that has the sound you want. Find a note in the middle of that channel's note range and try to ensure it's long-ish. You want enough to at least capture the essence of the sound. If it is to be looped (most FM synth sounds probably will), then be sure the timbre settles out into a fairly constant part that is reasonably loopable. Iirc if you use a player with speed control, the FM speed should only slow the music down but not change the instrument characteristics. So if the notes are going too fast to get adequate lengths of samples you could try slowing the playback down. The efficacy of this probably depends on the sound driver used in the game, and how it controls the FM operators. I'd imagine most of them use the chip itself and not some external envelope, so slowing down would work, but I can't be certain. I'm only speculating about half of this anyway since I haven't played with FM too much. But once you've got your sample you can convert to BRR, which is another field of fun experiences in it of itself especially to get a nice loop. I've made custom brrs before, so if you need help, I can give more definitive advice.

I'm afraid I can't advise you on spc and midi conversion, other than to tell you that there is a very old spc to midi converter simply called spc2midi. The midi files it generates are a mess, at least when I tried it. When it works, VGMTrans seems to be a lot better. I do wonder how porters make things that sound almost exactly like the original game. DO they find really good midi files and convert to mml from which they get the basic notes, and then optimizing by hand for days? Or is there some other automated process that helps?

--------------------
Make more of less, that way you won't make less of more!
Not sure how PetiteMM would handle midi files having all tracks on channel 1. You could try it. I think it would see the separate tracks but it might take more optimizing of the mml on your part. You could also try going into a midi sequencer and assigning each track to its own channel. I doubt this will be a difficult process, but you'll have to know how your sequencer handles tracks and channels. I imagine basic sequencers might try to put some of that stuff under the hood in an attempt to keep it simple for casual users, but most decent ones probably won't.

--------------------
Make more of less, that way you won't make less of more!
YOu did put everything on its own track, but they are all on midi channel 1. There is a large difference. In midi you can have many tracks on one channel if you want. Not so in most other formats.
Out of curiosity what do you plan to use to convert the mml generated by PetiteMM or whatever you're using to SMW mml? I"ve not tried doing that so I'm curious.

--------------------
Make more of less, that way you won't make less of more!
I wonder if that has to do with how the game's sound driver is designed. Maybe some of those midi converters are reading direct driver code, or maybe the driver is sending instructions to the SPC in a specific way which is recognized, and if a driver doesn't follow a standard or do things in an expected way, then the SpC won't be recognised? I have no clue how this works or what's going on, but I can imagine that being a big part of the problem.

--------------------
Make more of less, that way you won't make less of more!
Well, the ym2612 has quite a bit of control over operators, so it's not fair to assume that it can only do certain sounds or that it has a predefined sound set. Each operator has volume, frequency and iirc a built-in ADSR envelope. The last of these can create some nice evolving/smooth sounds that the SPC700 can only vaguely imitate. While the spc does have channel modulation which is a crude FM synthesis, it requires two channels to effect one voice (although it is possible to have one channel modulate itself). Even so, it doesn't seem to be designed to really make FM sounds. I think it's more for a sort of distortion effect.

--------------------
Make more of less, that way you won't make less of more!
Wow, if that sample you posted is indeed the SPC700, I'd be curious as to how it was made. One of those lead sounds could not possibly just be a sample, it's too consistent and organic.

--------------------
Make more of less, that way you won't make less of more!
I haven't looked in depth at your text file, though I do suspect it will need a lot of work, as spc2mml conversions normally do. However just by looking at your samples I see that you are using about 43 K of samples. The optimized group contains 16 K of samples, so that totals 59 K. That means that you have less than 5 K for sequence data and echo buffer. The text file seems to suggest an echo buffer of \$04, which sounds about right, that's I think 8 K, so that is already pushing you over the 64 K limit before we get to the sequence data and playback program. As you said in your post, the original SPC you made is pretty much full to begin with... The overhead created by amk and the 16 K optimized group is really killing you here.
Here would be my suggestions:
1. Make a custom sample group that only loads samples needed for sound effects and leaves the other slots empty. Of course this group should load samples from the optimized folder for the most efficiency. All of this will give you more room, but I know it's not recommended. Perhaps someone else can chime in and ellaborate on why this is not a good suggestion, since I've not really done much with that aspect. The one reason I can think of to avoid this if possible is that it's extra work for level creators as it goes against the default configs. With that said, I've seen it done on a few ports here.
2. Remove some samples or find smaller ones. A lot of what goes into making good spc music is not the depth of your samples though that always helps, but the music programming, with the goal of fooling the listener as much as possible into thinking that more than a few k of samples are involved in creating the music.
3. Don't use echo. This will leave you more room but will sacrifice some depth. It's the easiest of the three but it has its drawbacks to be sure.
Also out of curiosity, what are you using to compose original spcs?

--------------------
Make more of less, that way you won't make less of more!
I think the SMW hat, kick and probably snare could work in place of the f0 ones. That will take care of about 4.5 K. The orchestral hit you are using is another 6.5 K or so, so removing those samples alone might? just cut it. But it might not be a bad idea to see if you can take some of your existing instruments and find smaller samples. The slap bass especially seems a little large for a bass, you could probably find a smaller sample that will work. SMw might even have an instrument that would work for that, but I'm not sure right now.

As for tuning, I often find that getting correct tunings is far easier to sort out once the new samples are in place, then you can at least hear if they're too high or low and adjust.

--------------------
Make more of less, that way you won't make less of more!
Hi all,
This may be a somewhat unusual request, but I was wondering if there are any utilities to rip brr samples from Snes roms (sfc files) instead of SPC700 dumps.

The only way I've found to do this is to use a program like split700 to rip the BRr samples from each individual SPC file, then remove duplicates and go through BRR Player and remove the false positives. With as many samples as a game like say, Tales of Fantasia, Secret of Evermore, etc. might have, who knows how long I'd be spending sorting the mess of dozens of SPC dumps? If I was working on a specific port, this method would be fine, as I could just find a song that uses all the samples I need and extract them. But I'm going for just extracting stuff for future use here and trying to build an archive of brrs, and want to find the most efficient way of doing it. An added bonus is if I forgo the SPC dumps and just extract from roms directly, I'll have every sample the game uses, not just those used in the music or are included in the SPC dump. To a lot of people this may not be important but I like seeing those more hidden things.

I found a program called snessor95, I believe. It can see brrs in roms, but unless I am missing something, it can only convert to wav, not export brr. That program also seems to be a lot older than many of the brr decoders that are now used, I'd be hesitant to trust its decoding.
Does anyone have suggestions?
Thanks.

--------------------
Make more of less, that way you won't make less of more!
Yeah, I knew about that feature but am having trouble using it. Perhaps me being visually impaired is making it difficult since my screen reader program may not be able to see the SPC info displays. I'll play with it a bit more and see if I can get it to work, since that would be useful.

The main reason why I was asking about extracting samples from a rom instead of from spc dumps though is for archival purposes. So I can take a game I know I'll be using samples from, for no real purpose yet other than just to have them, and rather than go through the trouble of doing it through a myriad of spcs, I could just get all of its samples from a rom instead.

--------------------
Make more of less, that way you won't make less of more!
Thanks for the advice, but I don't know if this will help in this case because so far as I know, that VST only supports extractions from spcs, not roms.

--------------------
Make more of less, that way you won't make less of more!
Originally posted by Torchkas
I'm afraid there's no easy way to rip directly from a ROM (there are ways but you'll have to look up the internal BRR table and it's a bit of a mess and different per game).

This was my initial impression, that every game was different and needed to be done individually, but the old Snessor95 program seems to rip from roms. It can probably do spcs too, but I tested it with a couple roms and it seemed to get the samples out. Only trouble is it can't export BRR, only wav. So that's why I was asking if there was a way to just export brr, since Snessor seems to be able to see the samples in a rom somehow.

--------------------
Make more of less, that way you won't make less of more!
I've been playing with samplers and such for the past couple years as a curious little hobby anyway, and that is in part what drew me to playing with the SPC700. I've made a number of what I believe to be nice BRR samples, and as a rule of thumb I try to keep each sample below 4 K (about 8000 PCM samples). A fair few go over though, just because of the nature of some types of samples, ensembles especially are hard to shrink down without the disconcerting flutter of a short sample loop. To a point, it sounds cool, but once the loops get too short, I can't stand it anymore. I could ramble on and on about my experiments and how I handle different types of sounds, but I digress.
I'm curious about what type of sample you're trying to compress. I enjoy a challenge, so if you want, I can try to make a BRR of your sample that sounds as good as I can get it. When sampling for limited memory you of course have to make a trade between a longer sample with lower quality, or a shorter sample with high quality. I air toward the latter in most cases unless the sound in question can be downsampled without terribly significant consequence (The SPC700 interpolation works to your advantage with low quality samples). And you wouldn't believe how much a dark sound like a pad can be downsampled before the quality starts to suffer noticeably.
In regards to your questions about how much sample space SMw can take, as a rule of thumb I would try to keep your custom samples in a port below a collective 32 K in size. This is because the optimized group is already 16 K, and if you add 32 K to that, you'll be at 48. This leaves 16 K for the sequence data for the music and sound effects, SPC program, etc. And if you're lucky, an echo buffer.
I hope that helps somewhat. Let me know if you need more info on something.

--------------------
Make more of less, that way you won't make less of more!
Hmm. I wonder if group definitions can go right in the text file. That would be kinda cool actually. I should test to see if AMK will throw a fit over that or not.
In any case, I wouldn't recommend replacing an instrument. Instrument definitions like ADSR and tuning are stored in the asm files, not the AMK group text files or mml. So even if you make a new group the proper way in the groups txt file, and change @1 to a custom sample, you'll then be stuck with the task of working with all the default instrument setup that is assigned in the asm files. While they can be edited fairly easily if you know what you're looking at, I doubt it would be wise to upload such hacky things to the ports section of the site anyway, but I could be wrong. The alternative to editing the ASM is to use a bunch of hex commands in your MML to reset all those default assignments to ones that'll work with your custom instrument. I suppose if you did that with a non sFX instrument it could hypothetically work. If you do it with instruments needed for SFX though, then the SFX using the modified samples would sound different. IMHO it's more worth just starting your custom instruments at @30, as I think it's friendlier for hackers. If you want to conserve space, replace samples with empty.brr, add your custom instruments in the mml manually, and then modify sequences as needed to use the samples you want. It's a pain but from a user's point of view is a lot simpler to make sense of.
FYI there is a list someplace of samples that aren't needed for SFX but I'll have to find it.

--------------------
Make more of less, that way you won't make less of more!
Yeah, I figured the op didn't intend to make anything official and was just messing around, but I was trying to be cautious. I haven't tried replacing a default instrument for the reasons I said above. But if it is indeed possible to specify a group as you describe, then that is quite useful.

--------------------
Make more of less, that way you won't make less of more!
The AMK SPC you provide doesn't seem to have any sound. When I try to generate the spc from your text file without a rom, the SPC does have sound but it sounds very possessed. I haven't tried inserting it into a rom, but in any case this is not going well in its current state.

I really hate to say this, but I think you are taking the wrong approach. I could hypothetically go through the MML and look at what is wrong. But tbh the SPC I am getting from the MML is so unlike the original that I have no clue where to start looking for problems without at least thinking about rewriting it from scratch. Telling you what is wrong with every wrong command will just be overwhelming, but optimizing for you would result in so many changes being made that I doubt it would result in productive learning.

I don't know how much you know about editing and writing MML, but I think just trying to write some by hand would help you a lot, even if nothing worthwhile comes of it. The reason I suggest this is because automated tools only do certain tasks well, i.e. spc2mml is good at getting parameters from most spcs, PetiteMM is good for starting midi to mml conversions, but none of these tools should be used on a full track without a ton of proofing. When working on mmls, don't insert the music into a rom, instead you can use the -norom switch from the command line to just generate an spc. There's also a way to do that from the GUI, though last time I tried it, it wouldn't run for some reason though inserting into a rom worked fine. Once the track sounds fine, test it in a rom.

The music porting section of the AMK readme covers most commands. The dollar sign (\$) indicates that a command is a hex command. Hex commands have their own section in the readme. Make an MML with a few notes, and test commands you are curious about. Just experiment with one command at a time until you are confident you know what it's meant to do. When you begin to recognize and follow other people's MML, and try to guess how the commands they are using affect the sound, then you know you are getting somewhere. Things won't be nearly so frustrating or perplexing then, even when things arne't sounding nice. Once you are a little comfy working with it in plane 'ol Notepad or whatever text editor, then you can use automated tools as assets.

For geeks like me, this is a very exciting process. But I do sympathize with the mindset of just wanting this to work and not understanding why it's so hard. Unfortunately, I don't think it's possible to tackle something like this any other way.

--------------------
Make more of less, that way you won't make less of more!
Yeah, I can optimize the port for you if you want. I don't really mind, I guess I'm just weird. I'll probably start on that soon. Besides, there are weird issues with tuning in the original that I would've recommended be looked into.

AS for how you start with MML? Well that's a tough one. Basically I started by playing with a similar MML program for the Nes, I believe I started with that in 2009, and I read a basic tutorial on how to get things working. Once I ensured everything was working without obvious errors, I started looking at how notes and other things are written. Having a rudimentary understanding of music theory also helps when writing since a lot of the notation is based on traditional termonology. Letters A to G are notes, R is rest, putting a 4, 8, 16, etc. after a note or a rest gives it a length. For example c4 is a C quarter note. IIRC this is in the readme too, which describes most commands in brief with examples. My first mml was literally just a C on one channel, just to ensure things were making sense. Then a little chord or a five note scale or something. My first tune took me days of work, and that was for the Nes which is less complex. But I also was a perfectionist too, and because I was just learning, my perfectionist tendencies just slowed me down. They still do... and no matter how good you get, MML is by nature a slow process which I think you will either like or hate. I honestly don't know where my patience comes from.

If you're going to try and work out MML by hand, I'd say it's better to start with one of your ideas, rather than transcribe something. The latter is a great way to learn but it feels more like an exercise. Keep things certain i.e. don't resort to some mad guessing to get it right. If you want to use custom samples you can. Since that is an AMK specific thing, you could argue that it's separate from the MML learning curve. If you don't want to bother you can use the SMw sounds.

What I wouldn't recommend doing is starting out with a complex port because you may go too deep too quickly and be overloaded, and that's assuming the port is done well. If not then you'll be even more confused. I think it's easier to learn if you're writing it, then you can practice reading other's code if, say, someone asks you to optimize a port or you use a tool to do some of the hard work for you . It's also worth saying that everyone has their own style. For example, SPC2MML puts some commands in a different order than I tend to like, but that doesn't affect the sound. It can be easy getting thrown off if you're used to a rigid structure, simply because you're reading someone Else's script and not your own.

I hope that helps. Let me know if you have questions. I will post here when the port is done.

--------------------
Make more of less, that way you won't make less of more!
 Pages: 1 2 3 4 … 5–14567891011121314 … 15 16
 musicalman's Profile - Posts by musicalman