LinkoVitch Posted June 4, 2013 Author Share Posted June 4, 2013 too bad, i thought it's a Tracker... :-( If you want a Tracker, I'd suggest Open ModPlug Tracker, it's very full featured and supports all formats from the original MOD to XM etc. my sound engine is for playing back sounds and modules on the Atari Jaguar, not much point in having a tracker on the Jag itself (that I can see anyway). Quote Link to comment Share on other sites More sharing options...
Der Luchs Posted June 4, 2013 Share Posted June 4, 2013 But how will I know, which Instruments and Freq are supported by the Jag? Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted June 4, 2013 Author Share Posted June 4, 2013 But how will I know, which Instruments and Freq are supported by the Jag? A tracker module contains the samples for the instruments. If you can create a valid Tracker or Pro-Tracker module, then the U-235 SE will play it (with a few outstanding effects still needing to be implemented, but those will come in time.) For sample playback, as long as it is 8bit signed, most frequencies should be possible, not worth going much over 20kHz but you can if you want to use that much RAM Quote Link to comment Share on other sites More sharing options...
Der Luchs Posted June 4, 2013 Share Posted June 4, 2013 What about .ASM or XEX export? Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted June 4, 2013 Author Share Posted June 4, 2013 What about .ASM or XEX export? Not at this time. Just Modtracker or ProTracker Quote Link to comment Share on other sites More sharing options...
Der Luchs Posted June 4, 2013 Share Posted June 4, 2013 Ok, thanks! Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted July 13, 2013 Author Share Posted July 13, 2013 Version 0.20 released (changelog), Fixed bug with looped samples making small sample loops sound horribly off-key, Vibrato & vol slide added, added a pseudo random number generator... U235 SoundEngine Homepage 6 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted February 18, 2014 Author Share Posted February 18, 2014 Version 0.21 released (changelog), Small update. Now includes joypad reading feature.U235 SoundEngine Homepage 3 Quote Link to comment Share on other sites More sharing options...
sh3-rg Posted February 18, 2014 Share Posted February 18, 2014 NEW FEATURE: Joypad reading is now handled by the SoundEngine. Status of pad1 & pad2 can now be easily read via 2 longs Looks like vlad could kill 2 birds (or a small flock) with one stone if he builds this into his basic. 4 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted February 18, 2014 Share Posted February 18, 2014 Yep. I threatened to make Progress Quest if he didn't get real joypad support working. I don't think he's ever forgiven me 2 Quote Link to comment Share on other sites More sharing options...
Otto1980 Posted March 12, 2014 Share Posted March 12, 2014 hi linko tryed a little you u235SE very nice (also padreading/randnr) just some questions: dsp.obj is ~30kb how much of it you load into dsp local ram? plus 3 buffers? did i understand correctly? (you know im just curious ) is this a .mod only tracker? (didnt find that info in pdf ) nice work.. cool to have !! keep on this way greetz Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted March 12, 2014 Author Share Posted March 12, 2014 Glad you liked it the object is 30KB because it has more than just pure code in there. As well as the code there are all the linker labels etc, to allow it to be linked into other peoples code. It also includes the 68K to setup the Mod player (sets up sample banks, tempo, etc) and a lookup table or two. The DSP code is probably around 3-4K, and the rest of it is variables and sound buffers. Once a mod is setup it runs 100% on the DSP, you can test this by starting a mod and then issuing an 'illegal' or 'stop' to the 68K, it will keep playing It would be possible to write a parser for another mod format in 68K land and pass the playback instructions to the SE if you wanted to play something other than a SoundTracker/ProTracker mod. Internally this is how it works, the parser parses the mod and just creates playlists to pass to the SE internally making it nice a modular I bundled it all into the one object to keep things neat and tidy, just need a few files in your own project workspace to make use of it. You are right it does also have some buffers in the DSP RAM, there are 2 which feed the DACs, and each voice has it's own very small cache buffer. It is primarily a Sound Engine that just plays samples, A pad reader and RNG. I have also bolted onto it a Module parser so it can parse SoundTracker/ProTracker modules. The big picture would be that this can be switched out for other formats (Octamed etc), or possibly other sound sources (I have got some very rough CD Audio playback code kicking about, and also dabbled a bit with pure synthesis of sounds). There are still plenty of tweaks to be made to the existing codebase, and I think I can possibly improve the performance of the SE itself further and reduce its impact on the system bus hopefully. 3 Quote Link to comment Share on other sites More sharing options...
Otto1980 Posted March 12, 2014 Share Posted March 12, 2014 very cool... sound you on the best way to create the standard jaguar sound library is this buffering dynamic? or more static? example mod size: 20 kb 2 x buffer size: 2 kb each, so 4 total so you have 10 "buffer loads" are they static? i mean: buffer 1 gets kb 0 to kb 2 of the mod buffer 2 gets kb 2 to kb 4 etc, etc,... some theory just for my curiosity? Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 12, 2014 Share Posted March 12, 2014 Anyone caught using anything but mod music on the Jag should be strapped to an R-Zone and force fed items from Poundland. 2 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted March 12, 2014 Author Share Posted March 12, 2014 The buffers are static, they are only about 512bytes each IIRC (would need to go rummaging in code to confirm ), all they are used for is precalculating the output to feed to the DAC, once the buffer has been played it is re-computed whilst the 2nd buffer is played, and vice versa. The cache is only 4bytes per voice, although I am looking to change how most of this works. Unfortunately for a single pattern within a mod you need 1K of RAM, I did consider caching the pattern data, but given the low frequency that it is read and size of it made that pointless. I am also working on some alternative approaches to reduce the memory footprint of the module format, possibly leading to better caching and playback performance too. Anyone caught using anything but mod music on the Jag should be strapped to an R-Zone and force fed items from Poundland. Actually, I disagree I have always thought the Jag should be playing stuff that sounds much better than 4channel mods, after all the Amiga (*SPIT*) used 4 channel mods all the time, the Jag is so much more than an Amiga (*SPIT*) so I would like to hear it do more! (Yep I have my own ideas and plans around this ) 2 Quote Link to comment Share on other sites More sharing options...
Otto1980 Posted March 12, 2014 Share Posted March 12, 2014 ever thought about some kind of compression? Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted March 12, 2014 Author Share Posted March 12, 2014 Problem with compression is you have to uncompress it to use it, and you have to uncompress it somewhere. I may look into ADPCM, but that is only going to reduce the size of the source data and bus utilisation (potentially depending on LUT size) not the processed data. There are significant savings to be had by reorganizing of data structures as well as reduction in bus bandwidth and CPU utilisation 2 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted March 12, 2014 Share Posted March 12, 2014 Actually, I disagree I have always thought the Jag should be playing stuff that sounds much better than 4channel mods, after all the Amiga (*SPIT*) used 4 channel mods all the time, the Jag is so much more than an Amiga (*SPIT*) so I would like to hear it do more! (Yep I have my own ideas and plans around this ) Oops. My lack of 68k computing experience is showing. I was running mods like this on my PC back in the day: 1 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted March 12, 2014 Author Share Posted March 12, 2014 I'd certainly like to see what nice noises a Jag could produce with the involvement of a talented musician and some experimentation with synthesis stuff. If the synth sounds can be done entirely in the DSP then the impact to the bus could be very low, and we could have some nice 16bit Stereo audio coming out of our speakers. Not sure if the DSP can match the audio quality of an Ultrasound or anything with a Wave table, but it should be possible to make some really nice sounds. 3 Quote Link to comment Share on other sites More sharing options...
Otto1980 Posted March 12, 2014 Share Posted March 12, 2014 (edited) yes i understand the compression problematic now you maybe understand my previous questions the dsp speed itselfe would be enough for a simple decompress.. its just about the 8k and the task managing inside.. i am right? 8k of dsp ram and what is possible inside :D because... as you say ... compressed data is smaller... also smaller to transfer via bus.. also smaller bus-use by the dsp thats why i asked for the buffers and size and also dynamic or not just an idea or vision.. didnt think very deep into the topic yet greetings Edited March 12, 2014 by Otto1980 Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted March 12, 2014 Author Share Posted March 12, 2014 Yeah runtime decomp could possibly work, but this isn't really going to work for a file structure like a mod. Inside a mod file there are several tables of data. Sample data table, song data, pattern data and the samples themselves. When you play a mod you look in the song data to find what pattern to play, then in the pattern table you need to read each division of that pattern at the appropriate time. So the problem becomes, what do you compress? If you compress pattern data, you are possibly going to need to compress it into small chunks and then decompress those chunks when you read them in to be able to use the data. The smaller the chunk size the easier it will be and less buffer it will need in the DSP, but also the less compression benefits from that compression (depending on compression algorithm will depend on additional overheads of the process too). So compressing the song/pattern data may be too problematic to be of much use (a typical mod with a playspeed of 6 will only read 16 bytes from main RAM once every 0.12 of a second, so not a big hit) Data like samples which are pulled from the bus constantly typically don't compress very well due to their structure, you would need to read in (most likely) more data to be able to decompress the data you need to mix the samples together. And as you have mentioned, only 8K of RAM for use as buffer space. There may be techniques out there I am not aware of that could benefit things (I don't claim to know everything ), I am certainly not aware of any, and don't think for the work required there would be significant benefit. I am more interested in pre-caching as much of a sample as possible into the DSP RAM, then feeding the SE from these caches, the SE already does this but only for 4x8bit samples per sample, which doesn't sound much but it's effectively reducing the number of bus reads for a sample by half. (DSP has a 16bit bus, each read fetching 2 8bit samples, twice, possibly some benefit from 1x 32bit read rather than 2x 16bit reads etc). Quote Link to comment Share on other sites More sharing options...
Otto1980 Posted March 12, 2014 Share Posted March 12, 2014 yes.. i see we understand each other.. .mod module is already really small and the facts its a tracker (uses tracks) is already a kind of compression (only in view of size, not tech splitting a .mod into 2k pices and compress them, compile them into the binary to have memory benefit.. i think to much work for small gain. maybe now you understand my question about the buffers because for decompression you must know how huge a datapart is and how decompression algorythm works e.g. can you read kb for kb and decompress with the algorythm or does the algorythm require the whole datasection for his math. we do not even have 8kb for buffer.. cause a SoundEngine also needs his space, right? greets Quote Link to comment Share on other sites More sharing options...
LinkoVitch Posted March 12, 2014 Author Share Posted March 12, 2014 Well, not really .. If you load up a mod in an editor and look at the pattern data, one thing I have noticed is there is often a lot of empty space and repetitions. So quite a lot of the time there is wasted effort reading in instructions that are essentially the musical equivalent of a nop. If we were to remove all those holes we can save a huge (relitively speaking) amount of space, get rid of the duplicate data and save even more. And that's without compression! If you were going to look at compressing it I would imagine you would decide on a chunk size to break the data into, say 64bytes of data, then compress that. This way at least you will know that the uncompressed data will always be no more than 64bytes. My (basic) understanding of compression is around the Huffman approach and as such a kind of dictionary will be required, I suppose to remove the need to require one for each 64byte chunk you would produce one for the whole dataset, or at least a larger window to gain as much of an optimisation as possible. there may be some merrit to compressing the pattern data, however I doubt it will be significant, or give a significant gain to performance. I will bear it in mind and if the mood takes me, I may look into it further. There are however bigger gains to be had from much less work first Indeed, the 8KB already holds the actual SoundEngine code, it's variables, as well as some small buffers. It may be possible to allocate some of that for pattern data, but as I said earlier the amount of time spent reading pattern data is very minimal, and given the improvements I already have planned this would be reduced further anyway. Restructuring the mod data, working out a compression scheme and then the code needed to work with that is perhaps an interesting challenge but ultimately for small gains. Quote Link to comment Share on other sites More sharing options...
ggn Posted March 12, 2014 Share Posted March 12, 2014 If you want to toy around with compressed sound, grab the source code of Tripper and take a look. And then send a patch to Linko for his SE - as we all know patches are always welcome . (especially patches for closed sourced code ) 1 Quote Link to comment Share on other sites More sharing options...
Chilly Willy Posted March 13, 2014 Share Posted March 13, 2014 The venerable MOD format can handle more than 4 tracks - I've seen up to 32 tracks. My own MOD player code for the 32X and SCD handles up to 8 tracks, but it's super-easy to add any number of tracks. There's also XM (extended mod) format, which handles up to 32 tracks by default. I made a player for the 32X that works great, so playing XM on the Jaguar should be doable as well. MOD and/or XM should be sufficient for most Jaguar games. When you need a really odd piece of music or sound effects, ADPCM like Tripper plays should be fine. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.