.. (Page 6 of 10)

Sweet.  Thanks.  That has been on my list of things to do for so long.

If it's helpful to anyone I added it to sneskit+examples; add -D PITCHMOD to ASFLAGS to select KungFuFurby's version.

Most of the examples here are Anthrox demos slightly modified to use some of the SNESKit stuff.  The only thing using sound right now are the two snesmod demos and the pitchmod demo.

I will try to update with more documentation and such as soon as possible.

If anybody needs any help with this stuff or would like to help  make more examples message me.

http://www.morganleahrecords.com/august … kit.tar.xz

edited to update link; added snesgrit info and 63mbit template.  Archive updated August 8th 2014.

Last edited by Augustus Blackheart (Aug 9, 2014 3:21 pm)

mcm:
1. It hasn't been something I've considered. For the most part (notes + samples etc) it's trivial, but things like pitch bend effects and stuff probably don't necessarily match 1:1 with what .it specifies (our tool may bend stronger, for instance) and covering all of those corner cases isn't something that sounds very practical. Maybe it's easier than that; I mean, if nothing else I could always bolt one on there and leave those issues for you to fix in the tool (which I find pretty reasonable actually). If nothing else that would get you one step closer .

2. The tool is a PC tool that currently exports .spc's, prebuilt rom's and a somewhat botched source export that allows me to get the dumped music as source for demos but isn't really useful for much else yet .

kungfu: Looks like you've been spending a lot of time pulling apart my rom's The tool is a pc tracker like famitracker for snes.. superfamitracker I guess . There's a replayer that's a native rom, but it's in a VERY early state atm. We'll plan to be able to mute channels and stuff on the fly; it'll be mainly for playing back tracks live.

the main reasons we opted for a pc tool are for comfort: you really want to be tracking without the ram limits on the actual system, and you want to be able to reimport/encode samples very quickly on the fly. Since processing samples externally is a huge part of the process, iteration time needs to be as fast as possible. You can import .wav's whenever and there's an indicator for when you've gone over ram limit etc. It's pretty shit to try and track with samples and stuff with 8 buttons and a d-pad too, I'd imagine XD . Sure, LSDj gets away with something simpler, but so's the medium .

Also, this really simplifies the data model while actually working on the song, so the tool is inherently much more simple/stable. It's just less code . All the spc-specific transforms (minus sample encoding really) are done on export - pattern data gets split up into per-track components and compressed, samples are chopped at the loop points.. those kinds of things. But I guess you saw that stuff already ;D

so no, not a command line tool, as it's a full tracker. And it'll very likely be open source. Actually, the spc emu core that the audio engine is built on already is: https://github.com/yupferris/SamuraiPizzaCats (not done yet, but pretty close to what will ship in the tool. Better resampling and postproc are really all that remains for that purpose).

mcm: of course! the whole goal is to impose "what you hear is what you get" - the ram expansion in the tool is the only difference, and as I said, there's an indicator for when you go over . The rest of the audio engine is pure snes apu emulation; there's echo, noise and pitch mod too.

for samples, there's currently .wav import and .ins, which is a format I made for ripping/testing from other .spc's. It's basically just .brr with some metadata like loop point + envelope info, wrapped up in bson for extensibility.

Last edited by ferris (May 8, 2014 8:58 pm)

well, the ones from the tool will likely include this info, but in terms of instruments ripped from games, it's kindof guesswork at that point, so they'll probably be left out in that case. This actually isn't something I've addressed yet, so I'm glad you brought it up

adsr is a hardware thing, so it behaves how it behaves I'm currently working on a nice viewer for editing them, so it should feel pretty comfortable. Gain release will be supported.

As far as inverse/surround pannings, that's something I'll have to evaluate later. Again, not something I initially thought about

Also, do you have an example of that romancing saga3 stuff? never heard it myself

I actually have an idea for sample swapping that is theoretically possible with a sound driver. It's just that you have to do data importing and it is best done with sections of music that can loop while the samples are loading to avoid glitching (expect some samples, defined by the user, to be overwritten as samples are swapped in and our). The same can be done with actual musical data, meaning dynamic music is possible by importing sections of musical data whenever needed (or all of the data can be loaded at once and instead special branching commands can be put in there that are affected by whether or not a certain user-defined flag are set). Main problem is that this can't technically be done in .spc format (unless you want multiple .spc files for each section).

Also, I would recommend that it be able to support multiple songs in the SPC700 RAM (or even start from any point... your sound driver as-is appears to be able to support this feature on a technicality). I've invented multiple music modifiers in which the result is banked music in the sense that a variable number of songs were stored in the SPC700 RAM.

All that needs to be added on is the ability to make some sound effects (one channel or multi-channel), some command IDs to send them over, and you've got yourself a functional sound driver that could be used for a game.

Hey guys - update:  I'm playing a show on the weekend with a SNES using tunes built with the Alpha 0.0.7.  It's only going to be an 8 minute section of the show -  but I'll see if I can record it so you can hear the SNES in replay.

For all the technical questions - esp about ADSR and BRR techniques, etc - by all my accounts, the tracker and SNES output are very similar right down to the glitches in BRR looping to the ramping on the ADSR being spot on.  There is a slight difference in the brightness of the DAC .... everything in the tracker space is (at this point) slightly brighter.  However, with a treble boost on the SNES side... it sounds fine and very similar on real hardware.  We've been discussing implementing a modelled filter in the tracker replayer - but then again, every gen of SNES sounds slightly different (and also hums differently!).  Put it this way if perfect emulation worries you : our tracer is close enough that I'd happily play tunes live on a SNES even if I didn't have the chance to test the binary on real hardware before a show.  And if all else fails, fist pump and the crowd won't notice it sounds a bit muffled.

As far as when the public beta will be out - can't quite lock that down yet.  Ferris been workin' hard on the codebase to add more of the vanilla essentials (think everyday features like select, delete, copy, paste, undo! Oh, and a labelled interface too.)  It's been built backwards to what you'd expect - hardcore features first - basics last.  Meanwhile, I've been working on breaking each of these.  And I always seem to find odd ways to break the compiler because I'm trying to push each experimental build to it's limits :-P  Once something is stable, includes most basic features, and has a finalized native save format that will remain forward compatible - we'll get it out there.

End goal in sight : just workin' around various day jobs and demo parties ;-)

Last edited by cTrix (Jul 11, 2014 10:20 am)