Search options (Page 18 of 51)

from what i understand, .NSFs and MODs are each special cases.

.NSFs are more readily playable because the format is basically a wrapper for the original audio data, which equates to low-level hardware instructions.  if you have a emulator that understands these instructions faithfully, then it's irrelevant whether you used Famitracker or some closed-source dev kit tool to write the music, as long as you were only concerned about the result being a compiled NSF.

.MODs are "relatively" easily to decode and playback because the .MOD format is basically a bunch of info about the module itself + the note data + raw sample data.  that data tends to be hardware-agnostic, so you wouldn't need to faithfully emulate the original hardware; all you need is a program that can decode and play the samples in the order that the note data dictates.   (how accurate the resulting playback is to the original author's hardware is another story though). the MOD file formats have also been documented well enough that a programmer could accurately interpret the data.

.lsdsngs, by contrast, consist of data that does not directly correlate to hardware playback instructions.  for them to be more readily playable, you'd need a tool that could convert an .lsdsng into a .GBS file (which is the game boy equivalent of NSF files).   but all i could find through some quick googling is johan saying that to do so is "hard".

can anybody with more GB technical expertise (nitro2k01 maybe) elaborate on what exactly makes this process hard?  what's the significance of the "bank switching" that johan described in the thread above?

i think it would require a change in how cm.o handles HTTP page requests.  it looks like navigating around weeklybeats.com loads up pages through AJAX calls and replaces the previous HTML content, instead of actually refreshing the page.   this is how playback can remain persistent even when browsing through different parts of the site.

i don't know how much work it would take for trash80 to apply this methodology to this site, though.

alternatively, a "mostly" persistent audio player could be implemented, much in the same way that bandcamp does it now, whereby the player keeps track of the current track and play position in the form of a cookie variable.   when you load another page, the player would figure out how to resume playback from that point.  that method has its own pros and cons, though.

personally? i think just being able to load up a track in a new tab is plenty.  though for some reason, that functionality is disabled here.

unfortunately i missed out on a good chunk of the live stream because of some other events i was attending, but the parts that i did catch were positively banging!   as always you aussies know how to party.

was anybody genius enough to record the live stream locally?  to get a hold of it would be aces.

i dunno guys, i tried it and i don't really see much of a productivity increase tbh:

oh just great, yet ANOTHER chip wild-west themed split EP.   come on chip scene do something original!!!!

for actuals though, this rocks hard, definitely a unique concept.  excellent work.

question: when loading a project from flash, is it possible to detect and warn if the SAV currently in ram needs to be saved in flash memory first? 

unfortunately i learned the hard way that even if you save a song to the current SAV, those changes aren't permanent unless you actually save the project.

update:  nope, doesn't really change anything on the DS (it's almost certainly the fault of the LameBoy emulator though).

still though, there is a noticeable difference in sound quality on my GBAs, a little hard to tell though because i'm generally averse to kits.  thanks a ton n2k1!

btw, what effect, if any, might this fix have on cpu usage?