-
Content Count
367 -
Joined
-
Last visited
-
Days Won
1
Posts posted by VinsCool
-
-
Just for fun I recorded a few executables I had around since I was playing around on my machine for some other tests and recordings
Those were recorded off a NTSC 800xl.
This sounds pretty damn cool!-
5
-
1
-
-
38 minutes ago, ivop said:Sure! We'll get there in the future
Just listen to Synthpopalooza's exo-area5. Some parts sound almost like a SNES.
I have, it's really awesome stuff, he's been sharing a lot of his research on the Atari Chiptune discord lately, and that stuff was exactly what motivated myself to get a lot further with the POKEY sound generation, and a lot of his own tables had helped me greatly for several of my own tunes already!
It's so much fun to create "impossible sounds", even more when it makes sense as to how and why it can be done
40 minutes ago, ivop said:Somehow I'm "working" on an 800XL keyboard replacement for over a year now
So many unfinished projects. But I did Pokey Explorer last year, so not all was lost
I like it that you use it, too. Thanks for the compliment the other day. That really means a lot to me.
You're welcome! Yeah I can get ahead of myself too many times, and get lost in some ambitious projects I need to put in stand by simply for either being too difficult to realise (my rambles regarding RMT's implementations of several things is in direct relation to that!), or take so much time that I simply couldn't get it done, or when I manage to, it takes an eternity to complete (the Battle Squadron cover, for example, took me nearly 2 weeks of evenings I had available as free time!), or just get halted to a full stop for a combination of every reasons (Electric City anyone?
).
I seriously love POKEY explorer! It truly lets me experiment with sounds so easily, and it has helped so much for my own research regarding frequencies tuning, impossible sounds and very creative sound design too!
One of my WIP tunes called "A Permanent Temporary Solution" relied heavily on ideas I got when I was poking around in the program. A Permanent Temporary Solution V2.xex
That thing is also unfinished but I think you get the idea behind it
It's also one of the few projects that relied on my "hacked up" workflow which consists of manual AUDCTL settings, hacked up instrunents based on serious usage of commands 1 and 2, duplicate instruments, and more instruments, just to get the exact tones and frequencies I needed.
And that is the exact kind of projects that make me scream out of (exaggerated) frustration due to being limited by the music tracker itself
Thankfully, as Rensoup said: LZSS rules! 😆-
2
-
-
Of course I did not mean to sound ungrateful and demanding when I posted my rambling the other day!
Just what is available to use is already excellent, and a lot of fun to play with.
it's getting into "expert tricks" territory that makes me realise how much things could have seen improvements
Speaking of which I have still been trying to get better tuning going... Made little progress but valuable thoughts from friends has been very helpful.
That's about getting more for personal usage at this point, but thankfully it's the results that really matter
Anyway with new knowledge at hand I wonder what my next finished tune will be, and how I will be able to execute it... I mean I got way too many projects I didn't finalise for a reason or another 🤔
-
1
-
-
2 hours ago, rensoup said:This is the RMT player code which is located in the source folder of every RMT release... (I converted it to C# for RMT2LZSS). There's no 'best' version really... 1.28 is the last version, the patched versions are just different.
Although adding new tables to the player isn't that difficult, the player is embedded in the RMT editor (I'm 99% sure) and it's quite messy to follow because it is optimized for space (just have a look at rmtplayr.a65 !).
So even after modifying the player you'd have to reinject it into RMT, that could be very messy...or not but I'm guessing that since Analmux didn't do it, it's probably the latter.
Then you'd have to modify the editor interface to be able to select those tables and pass that back to the player... Without the editor source code, that would probably take a good chunk of time.
I just looked at the source files you mentioned... damn that looks surprisingly straightforward, I really don't see why there couldn't be any more slots available by the look of it, other than memory concern, but that's not a massive amount of data... right?
I can also see vibrato tables (and frankly it looks like it could have more options), a nice implementation of 16 bit (with unique tables for both low and high byte! Clearly there is much more potential for that alone), volume levels table (which is actually something I wish I had known before, it was always annoying to guess proper volume levels being adjusted, I also wonder if there isn't a way to optimise that in order to save precious space to maybe use elsewhere 👀)... and then the manual AUDCTL settings, which were the ones I have personally been using in the tracker itself for a while now.
Most interestingly, only 3 unique tables for notes, which happen to be 2 bass tables (as C and E), and 1 "pure" table, and each one seem used for several setting, which explains why editing a table breaks other things, that's literally because they're used more than once, and I do know that everything requires a unique table to actually sound good! 😰
dta frqtabpure-frqtab,$00 dta frqtabpure-frqtab,$20 dta frqtabpure-frqtab,$40 dta frqtabbass1-frqtab,$c0 dta frqtabpure-frqtab,$80 dta frqtabpure-frqtab,$a0 dta frqtabbass1-frqtab,$c0 dta frqtabbass2-frqtab,$c0
So just by the look of it, that makes sense, now I know why several things "broke" from only editing the "pure" table, it is also used in instrument type 0, 2, 4, 8! 😟
It's pretty clear to me, there are more tables that should exist in the first place... I mean, each ones of these distortions need its own table, otherwise stuff sounds out of tune, or just plain wrong.
Another interesting thing I have noticed from my own experiments, thanks to POKEY Explorer, different modes (15khz, 64khz, 1.79mhz), combinations (16-bit, Joined 1+2/3+4, Filter 1+3/2+4, even several things at once!) really produce different results, and so there is simply no way a single table of notes could work for everything, this is the opposite of how it was implemented in RMT! 😱
And so, that probably sums up my observations, considering the tracker is not open source (to my knowledge), it's really not a great time to hack around, since it's literally going to be required to use several hacked versions to get certain specific things to work, and doing them by hand in the instrument editor is painfully slow for a musician who doesn't know how to code...
and just now I realise how handling tuning becomes even more difficult due to its implementation 😨
To get optimal results, it's clear to me that having a way to load custom notes tables could go a really, really long way, especially if each ones could be used for specific cases.
For example, I was able to prove that tuning Distortion A notes to a certain set of frequencies could be improved, and then noticed around the same time that a table working well for 64khz mode will sound weird in 15khz, and vice versa, same for 1.79, or the other distortions themselves, since they pretty much all live with similar behaviours.
It looks like everything is there, so clearly editing the player code may be a very easy task, like you said earlier, it's the tracker itself that is pretty much out of reach.
I mean even an idiot like myself, who hardly knows any programming, was able to edit the executable to replace the Distortion A table for my own. But this is about as much as I am capable of doing
Now, I wonder if I am not getting into a rabbit hole, regarding tuning and other complicated stuff, instead of just trying to make music 😆
I can clearly see how it good that chip could be, that I am the most definitely certain about! So much potential to understand and make use, hopefully.-
1
-
-
6 hours ago, Pat Brady said:I am glad you find it useful.
It's all based on formulas. There are formulas to figure out what frequency each note should be, and formulas to calculate the AUDF value closest to each frequency. Now that all of that stuff is established, adding tables is much much faster than doing it by hand.
For now it is just distortion A (16-bit and both 8-bit clocks) and distortion C (3 different pattern lengths). I think my formula for distortion 2 is incorrect, so I need to sort that out. Then I hope to eventually add some of the more esoteric settings.
Awesome!
I pretty much did a mix of calculation and doing tests by hand, and that has been painfully slow for the progress I got so far, so having these calculated tables at hand will drastically make that stuff much faster!
The other distortions aren't a top priority for me since they can only be as good as they already were anyway, so as long as there is a decent amount of compatibility to the distortion A tables that will work for me
5 hours ago, tane said:Regarding patching RMT, are these files the best version available?:
rmtplayr.a65 23.78 kB · 1 download
rmtinclude.asm 756 B · 1 download
rmt_feat.a65 2.71 kB · 1 download
That I really don't know! I am not too advanced in hacking RMT around in the first place, and really don't want to be for many reasons, however these files will be incredibly useful to have around, so thanks for sharing!
Stuff like that really makes me wish we could actually load custom notes tables for instruments, honestly 😰. Things would be so much easier for everyone.
There's too many things to consider and it feels a bit underwhelming to be limited by things like tuning to be able to make tunes sound good.
-
1
-
-
@Pat Brady wow I just took a look at your tables in the google docs... holy fuck this is awesome stuff, it's all exactly what I was looking for and what I was attempting to do with my own set of frequencies as well!
Thank you so much, this will totally save me a lot of time trying to calculate everything by hand and by ear
In fact, from what I could tell, I got really darn close to a mix of your Major 64khz tables, which looks like I had kind of "combined" based on the notes I was able to find resonating nicely together, so I really was on the right track!
Seriously, thank you so much!-
3
-
-
1 hour ago, Pat Brady said:I have a bunch of key-specific tables you are welcome to use:
https://docs.google.com/spreadsheets/d/148aza1TfSvlUZeSx6haHcU4IKwpYF8N7BxPbGRDA_f8/edit?usp=sharing
Each table is based on either 15 kHz or 64 kHz but also provides the closest values using the other clock.
If you need a key that's not there, let me know and I'll see what I can do.
Thanks a lot! That could be really helpful for what I'm trying to achieve.
-
Ah I see now, unison and octave resulting sound, that's indeed very pleasant, and a bit too easy to get weird because of the tuning.
-
8 minutes ago, ivop said:Here's something I'd want to do for a time after pokey-explorer. This is a spreadsheat with all 16-bit and 8-bit tunings for distortion 10, both PAL and NTSC. You can fiddle with the clocks (these are 800XL clocks), but you can also change the frequence of A4. If you change it to something else, all values automagically change. Everything from Handel's tuning fork at 422.5Hz, Beethoven's fork at 455.4Hz, and everything in between should word
All tables are tunes towards 12-TET (12 Tone Equal Temperament). It could be nice to replace the 12-TET column with a different tuning. For example, if you know your song is in D Major, you could put a D Major just intonated table in place, and let the spreadsheet do its magic, and return to pre-Bach just intonation. Like a breath of fresh air. On a G string
That would be pretty damn cool! especially considering how the POKEY tuning is limited, it would help a lot on some tunes to achieve the best possible harmonisation
The values I theorised here were based on as many notes as possible I could get in-tune to each others, and I believe the same principle also applies to distortions since I got my Distortion C bass to suddenly sound "in-tune" as well, as a side effect, which was unexpected but really welcome.
There's still a lot of improvements and most likely more alternative tables that could come into living from this concept, and I do plan to experiment with these for sure, hahah.
hopefully I can get a finalised table for $A in both 64khz and 15khz modes that are compatible, so far I was at least able to get a preliminary 15khz table that has the 2 first octaves in-tune to A-4=440, but it will be complicated to use since (at least, RMT) can only use the same table regardless of the mode used.
And doing the fine tuning manually in the tracker itself is technically possible, but it's painfully slow and very easy to mess up lol
Edit: by the way, I am so thankful for POKEY Explorer, it has helped me so much figuring out tuning and combinations of sounds as well as many more tricks I am starting to use more and more
-
2
-
-
1 hour ago, Philsan said:Awesome! PAL version please! 🙂
There you go
Corridors of Time Alternate Tuning 50hz.xex
It sounds a bit different since I only really adjusted the tempo, nothing else was changed.
Tuning may be a bit off as well, but I plan to look into PAL later as well
Oh yeah might as well post the modules. They rely on the tuning of my custom notes table in the RMT version I posted earlier in the thread, but otherwise they might still work fine in Vanilla RMT 1.28 (1.30)
Corridors of Time Alternate Tuning Final Loop Adjusted.rmt Corridors of Time Alternate Tuning Final Loop Adjusted 50hz.rmt-
2
-
2
-
-
1 hour ago, emkay said:Yes. The "bass" is the SID's real benefit. There is no chance to play such bass with POKEY.
15kh mode, or 16bit tuning combined to high pass filter can work for creating convincing SID bass on POKEY
-
3
-
-
Doing some custom tuning is slowly paying off, but there's still a lot of things I need to figure out.
Maybe I'm crazy or maybe I'm onto something but I hope I can fully get most notes to sound better between each others.
For now I only changed the Distortion A in 64khz mode tuning table, where the actual pattern of notes being "in-tune" appears to be around 444hz in NTSC, running the same frequencies in PAL is a near 440hz pattern 😮
For the moment I had to make my own patched RMT version to actually be able to test what I have figured out without having to make an instrument for literally each note, but that did work well I believe.
A few notes may still sound a bit wrong but otherwise most do sound pretty good together, there is a nice resonance going with the distortion bass now :3c
To make that RMT2LZSS conversion I had to be a little creative but thankfully that did work well, haha
In short I exported a .xex from the patched RMT version I made currently, recorded as SAPR in Altirra and then threw it into RMT2LZSS.
The song looping twice then fading out was actually done manually, couldn't be bothered to manually make the "loop" out of a SAP dump
The RMT version itself is actually nothing too special, it's just the Distortion A table changed to my own table, which is still not perfect so I wouldn't recommend using this one seriously, in fact I do not like having to rely on a hacked version at all, but it made my tests a lot easier to do
The .txt file is mostly a dump of ramble, ideas, and guesswork, so again I do not recommend taking anything from it too seriously, but maybe it could be useful, it's definitely something I want to improve later.
Corridors of Time Alternate Tuning.xex Rmt Vin Tuning Patch V1.exe POKEY Table 64khz (A=443hz) WIP14.txt
-
10
-
-
1 hour ago, rensoup said:so what's the original like ?
If my ears aren't deceiving me, this is the tune.
-
1
-
-
On 2/22/2021 at 6:50 PM, rensoup said:But that means you wouldn't be able to listen to your tunes in RMT right? you'd have to convert them to LZSS every time 🤨
That really depends on how much changes would be done in the first place too.
If for example it's mostly a tuning improvement, that would still work but most likely sound weird in RMT itself.
If it's a listenable state that would at least give an idea of what happens before conversion.
I've gone to the point where I rely on export/conversion behaviour in Altirra (and now real hardware!) in the first place anyway, so having to convert a couple times between versions isn't truly annoying me
I personally would totally love this instead of manually tune notes or make hacked up instruments just to get something to work, the only difference would be that it would then become RMT2LZSS exclusive features, hahaOn 2/22/2021 at 6:50 PM, rensoup said:I imagine you'd want a note table per instrument ?
It may be possible to have a file that contains all the notes (always 61 entries or something, right ? ) and just point to it at conversion time. If an instrument is skipped, it uses the default table
Something like this: (anything after ';' is a comment)
QuoteInstrument00
FE ; B-0 30.8
EF ; C-1 32.7...
00 ; B-8 7849.9
Instrument01
...
It's so clunky... but doable.
Exactly this!!! Yes!
I've been doing quite a bit of tuning and combination of frequency/AUDCTL stuff and they absolutely require very specific set of stuff going, making them work manually in RMT isn't impossible but it's becoming overwhelming when you get 10 extra instruments for a handful of notes, haha
Even worse is that RMT by default does not even have the most optimal tables of notes for most distortions and modes, so a lot of the stuff, if not all of it, sounds out of tune as a result, which probably gave the chip such a reputation for the last few years --for most people, or even myself until I tried to dig a little deeper with that stuff, it starts sounding weird very quickly.
Back to a year ago when I attempted to poorly cover the Prince of Persia tunes (I'm still a bit sad about deceiving you about it...) I didn't actually understand why things just sounded bad (or good), and that was directly related to this. There was a lot of stuff that was just... coded as is and then it was up to the user to figure it out.
Clearly a more experienced person can get away with it, but for those who don't know the chip very well, it made absolutely no sense, and then stuff just sounded that way because of how the note tables were implemented, which clearly contradicts more recent, and better tunes even an idiot like myself was able to do with some (a LOT of) dedication and manual tuning being fed into the projects
In fact now I totally understand the motivation behind patched versions of RMT, it's pretty much a necessity if you aren't patient to get certain things done manually, and it's also far from being the most user friendly kind of stuff as well.
Having a feature as such would make certain projects INFINITELY easier to manage, seriously 😮
As much as I love using RMT to make Atari chiptunes, there's so many things that could be done better, and it makes me sad to know there aren't many alternatives that don't require a musician to also learn programming or have a workflow made mostly of hacked up instrument and tracking design (the latter applies to myself currently, haha).
Its creator is also no longer with us
, and all we can get for now is either a handful of hacked versions that aren't even cross compatible between each others (a module created in one will sound wrong in the other and vice versa), or a lot of patience and a very hacky workflow, which was absolutely necessary for me to achieve some better sounding tunes.
All that bit of rambling to say how much I am thankful for the dedicated people who have helped me a lot to learn new tricks and improve my own skills, and having tools like RMT2LZSS is really awesome to push the elaborate sound design further.
Who knows, maybe we'll get a new tracker someday, and maybe there is still a lot of surprise from the 8 Bit machines awaiting to be found!
On 2/22/2021 at 6:50 PM, rensoup said:Impressive and disappointing at the same time 😀
Crazy quality for 50hz, file size is about the same as .RMT (but perhap .RMT could be trimmed down ?) but then I'm a little disappointed that 100hz didn't make that much of a difference!
Thanks! I also agree for the disappointing part lol
I knew it was possible to get 50hz design to sound good, but in reality it's only just the 100hz tune with some tweaks that was played back with every other frames skipped, which is surprisingly not that bad after the tweaks!
I'm pretty sure 100hz could produce even better results, but I am not the most skilled to make use of it at its fullest yet
I believe the .rmt could indeed be trimmed down considerably too, having a lot of instruments (and I mean, a LOT because it was absolutely necessary!), volume/speed commands and unique patterns that cannot be optimised further eat up a lot of memory very quickly.
Speaking of optimisations, how does LZSS work at its core anyway? Is it entire song compression? Or are there some special tricks involved to reduce file size?
I have noticed that just playing a couple identical patterns for a few times can drastically increase the file size, which makes me wonder if there couldn't be a way to literally remove any redundancy by making certain parts (like, patterns specifically) only compressed once, and then having them called into memory each time they are needed instead of adding them up infinitely?
A bit like how the loop point was implemented, except it would then become part of the whole data output, being made up of "subtunes" that can then be loaded each time they're actually required, which would then avoid having any duplicates in the compressed data, similar to the way trackers are made, if that makes any sense
Speaking of loop point, I was wondering if there could be a way to actually chose how many times a tune would loop, until maybe fading out using a very crude volume change based on the volume offsets?
Actually there would be many things that would be nice to have but I don't wanna start to sound like a nagger so I'll leave that for a better time and thread
-
2
-
-
Well speaking of experiments I finally gave a proper attempt at converting my Battle Squadron cover from 100hz to 50hz and got very positive results!
I'd consider this one about 90% identical to the 100hz version, which is really impressive in my opinion
Battle Squadron Title 50hz Reduced WIP.xex
So how did I achieve it actually? I didn't even try to rearrange my module from 100hz design to 50hz, I actually let RMT2LZSS do all the work for me, and only adjusted the module itself to find out what frames were "skippable" and what shouldn't be, so I was able to make up a direct conversion with barely any losses! Pattern data remained intact, I only had to adjust the instruments themselves, and sacrifice what had to be sacrificed to fit half the amount of frames used to forge the sounds.
It's not perfect yet but I think that speaks for itself just by the sound, I think
I'll try to polish it up a bit more later, but that may be as good as I could make it I think.
-
3
-
-
2 hours ago, rensoup said:Although I've converted the RMT player, I'm not 100% sure how that table stuff works 😮
So do you select a Pokey setting, then play all possible frequencies with Pokey explorer and figure out which ones correspond to a note? Then the table is just a compilation of all the valid notes ?
More or less, yes that's exactly that!
How to use the said table of notes is an entirely different story, however
In my case, I did all my notes by hand using several instruments to match my frequencies, so that in return remains 100% compatible with RMT 1.28.
Most people seem to prefer hacking RMT directly, which also works a lot better on the long run, but then incompatibilities between modules and RMT versions bothered me so I tried to be a little bit creative with my tunes instead. haha
2 hours ago, rensoup said:With RMT2LZSS it's pretty easy to add tables and patches and even have them all available together although obviously there's no interface (tracker) to select them so it's kind of useless.
That honestly could be really awesome, actually... To have a way to apply our own set of patches and frequency tables directly into RMT2LZSS, that would make certain experiments infinitely easier!
Something like overriding the original RMT tables with custom ones right in the conversion process 😮 No idea how that could even work however.
Having a new tracker would be even more for sure, but that might take a really long time, I imagine 😆-
1
-
-
A few days ago I started doing an experiment related to the tuning itself.
I have noticed RMT uses the same standard Distortion A table for both 64khz and 15khz modes.
While by itself that isn't a big deal, I eventually noticed that almost everything in 15khz mode was out of tune due to this implementation.
So I ran my own attempt at tuning notes directly using POKEY Explorer and a tuner as a reference, then wrote down my own table of notes.
Even if not perfect, it's considerably better compared to the original implementation, making octaves 1 and 2 (bass range) a lot less off I think.
It's not very easy to make use of it manually, but not impossible either, just takes a bit more time to get it to work without having to hack RMT itself.
So here's a quick test I did using one of my own tunes in progress, which was the ideal candidate for that test since it uses mode changes very heavily.
Note that I only applied the changes on the bass itself running in 15khz mode, everything else was left unchanged, so it might still sound a bit off as a result.
Just compare to the recording in the post just above, I hope this could be a useful improvement over the original out of tune bass
(Edit after reloading the page several times: sorry for posting links to an external place, looks like the site is very slow right now and I'm unable to attach files >.<)
15khz tuning table for Distortion A, NTSC: POKEY Table 15khz (A=440hz) V1.txt -> I also learned a bit later synthpopalooza made one before me, which is also almost identical, haha
Test tune using the improved 15khz bass tuning (without actually changing the normal 64khz mode): Temple of Questions Tuning Test 6.xex
The same tune in progress that was posted in the previous post above, with the lovely 15khz bass being out of tune
Sketch 24 v36.xex
-
1
-
-
1 hour ago, rensoup said:While that's good news, I still don't see any significant difference between the way LZSS and RMT send the data to Pokey... I added an option to remove the Pokey data simplification but @VinsCool said it wasn't the problem
I really don't know how to describe either, honestly...
It just seems like LZSS data fed into the register is a lot more stable and likely to produce predictable results, which is a really good thing, in my opinion!-
1
-
-
Been revisiting an old tune of mine, been a lot of fun to design so far
-
4
-
-
Tried to be a little more creative with the video format for this one!
The Tower of Turmoil - The Atari PoKEY Cover Soundtrack (Recorded from Real Hardware)
The audio itself is also available in the GDRIVE folder I posted in the other page.
-
3
-
-
5 minutes ago, ivop said:Not clipping as much with a higher volume is due to the analog nature of the audio mixer on real hardware. It goes through several opamps (at least two), and some RC filters.
That would make a lot of sense. I noticed real hardware was also quieter, and I had to manually amplify the sound when I had it recorded, but the quality doesn't suffer from it, thankfully.
-
6 hours ago, emkay said:Nice to hear "real" recordings. Not those "stereo quirks".
One POKEY set to the center of the speakers.
Also, those real recordings show that Altirra still sounds to much of plastic.
Altirra has been surprisingly really good from my own tests, everything expected in Altirra happened on hardware almost exactly the same, which is really good news to me.
Hardware has that hum and hiss that doesn't exist on emulator, however, and seems to not clip as much as higher volume, so a few things that sounded distorted on emulator sounded perfect on hardware, which is once again really good news
I think the real deal was how my cover of Battle Squadron was behaving on hardware. I used a PAL 800xl, the executable ran at 100hz, and everything I had finely put together using Altirra as a reference was accurately reproduced, and sounded even better than ever.
The only downside was that when I recorded individual audio channels, few things were impossible to fully predict because of the nature of the chip, such as buzzy Distortion C bass timbres or noise.My oscilloscope and the sound recorded from the full tune didn't 100% match visually because of it, since I basically had to record that tune 5 times, once for each channel, but it was good enough to for me.
The pulses manipulation using high pass filter were perfect however, because I had absolute control on them, they were predicted and very consistent. As show in the channel 2 of that video, the pulses were exactly how calculated throughout the entire song, and leaving it to loop for several times still produced identical results, hahaha.
I have more stuff planned to be recorded that way too. Not everything will be recorded 5 times to make fancy visuals however, because that takes time to actually record and synchronise everything
One thing I can say for sure, however, all my future work will (and should!) be intended for real hardware playback accuracy, and now I know Altirra is a really good emulator to get the overall idea of what it should sound like
The RMT2LZSS conversions also make things a lot easier for me, for example using the volume offset to mute channels, that saves a lot of time over editing the .rmt modules several times
Anyway speaking of hardware recording, I have got this edit you sent me a while ago that I really liked. I had changed it a little bit, but the overall idea is still there. The end section sounds so organic, compared to what I originally did.
This is actually where I began to understand how the chip really worked, and has since been the design I have used and improved for my later songs.
I might try to touch it up a little more someday and make a new upload to replace the version I have made first, which I can tell isn't very good compared to what I can do now.
This edit however, sounded great on hardware
I recorded it off the PAL 800xl as well.
-
5
-
-
Tried something a little different with the video format.
An old soundtrack, featuring real hardware recording.
Haydenwoffle - Atari PoKEY Soundtrack (Recorded from Real Hardware)
The audio itself is available in the GDRIVE folder I shared in the previous page of this thread too.
I'll make a couple more uploads like this, with a bunch of stuff I never released as well, soon
-
4
-
-
2 hours ago, emkay said:Uppedaatee..
I'm disappointed, I expected my module would have been used for this version
The high pitched sounds in the intro running at 1.79mhz are a little too high pitched to my taste, too
-
1
-

Trying to make some PoKEY music!
in Atari 8-Bit Computers
Posted · Edited by VinsCool
Site being slow... 3rd edit, I hope it works...
Been recording some more stuff on hardware
Corridors of Time (Alternate Tuning) This one sounded great on the real thing!
Some tunes by Spring, which were then converted exported from my sloppy tuning changes in RMT, also sounding great!
Some tests based on the manual 15khz tuning, and the original WIP version of the same tune:
And some tuning fail due to a mistake i made in the hex editor earlier, everything was off by 1 semitone, but I thought it still sounded nice after I transposed the bass down so here is it
Wow Atari Age really did not like me making this post. Too me several attempts to upload the audio files ._.
I hope this time it will work lol