Jump to content

VinsCool

Members
  • Content Count

    298
  • Joined

  • Last visited

  • Days Won

    1

VinsCool last won the day on May 24 2019

VinsCool had the most liked content!

Community Reputation

584 Excellent

6 Followers

About VinsCool

  • Rank
    Moonsweeper
  • Birthday 05/02/1995

Profile Information

  • Custom Status
    Persona Secretiva Felineus
  • Location
    Québec, Canada
  • Interests
    Video games, chiptunes, food, and Atari, of course!
  • Currently Playing
    The game of Life
  • Playing Next
    The game of Afterlife

Recent Profile Visitors

3,049 profile views
  1. So as far as I could tell everything I expected worked as expected. I need to test the 16-bit stuff further but it seems to be all good to me, tuning should be easy to do, unlike 8-bit I won't need to actually fight against limitations of pitch accuracy to get a decent table Distortion and Tables Test3.obx Distortion and Tables Test3.rmt Distortion and Tables Test3.erti
  2. Continuation from earlier, after a bit of math I figured out what I wanted to do earlier today, so here's a spreadsheet that calculates both PAL and NTSC, Distortion A, 16-bit, 8-bit 15-64khz and 1.79mhz, All of this is going to be really useful soon This was based on @ivop's sheet, so most of the formating is the same but I adjusted the equations for the new columns I added. I should start a new thread sometime... I also was supposed to test some RMT2LZSS stuff but kind of got carried over oops. Good thing I don't need to get up early tomorrow hahaha Atari Tuned A4=X (8-16-bit-15-64khz-1-79mhz).ods
  3. Ahh I see, anything would work really. Ohhh that could certainly do, I got a large amount of known frequencies I had noted down with more or less accuracy, so adding the few that are missing could then be used to calculate as well. Thankfully Distortion A in 15khz, 64khz, 1.79mhz and 16-bit are very easy to calculate based on the clock, only these would give a huge reference point. I'd totally give it a shot, all I need to know is how the math formula would be done to produce something out of these
  4. This is honestly the entire reason for my frequencies experiments: circumstances. Something that works the best in a given situation 😛 I imagine it should be easy enough om the same sheet to add with a simple formula? i was also wondering how could it work for tuning based on existing known frequencies, that will be especially useful for distortions and exotic combinations
  5. This is still something I have been playing around with, and honestly, as far as thing were going for me, most of my Alternate table actually has several things wrong now after reconsideration, but I have made an interesting observation. I was actually really close to it, 443.9hz (or 439.8hz in PAL) is indeed the most in-tune solution by far, and while I went with tuning intervals in the process, I realise now several notes became wrong as a result, but the initial idea is pretty much as good as it could be for the 8-bit pitch resolution. You are also correct, 432hz, or anything trying too hard to meet 440hz (that is more like 433.4 for PAL and 437.8 in NTSC if everything still use the 1983 documentation) don't work very well, after the first 2 octaves it goes wrong really quick. I honestly thought I went too hard into it, but it turns out I was getting very close, there will be unfortunately several notes that are off, but compared to a majority of them being wrong, it's only a few that get several hz away from the intentions, and that gets only really bad on the octave 6, unlike the original tables being offtune as early as octave 4. Just some things I had been looking again and hopefully could be improved with some changes here and there for later That also gives me the green light to tune 16-bit that way as well, since I know 443.9 will become 439.8 in PAL, which is pretty much as close as 440 could be. Most of the values are cross compatible too, so it really is close to the best it could be now. I must say thanks to Ivo's spreadsheet, I was able to play with it properly now and I was amazed to find out a majority of my Alternate Tuning was in reality quite good for the most part, and the interval problems mentioned earlier did indeed show up for a couple notes, the same ones I tried too hard to tune, it simply caused more issues on the long run, haha. Sooo I guess it's just to do a few changes here and there, adjust the other tables if necessary, and that should be good enough, hopefully. 16-bit definitely gives a much smaller error margin, thankfully.
  6. Tuning is both fun and frustrating, but at least I improve my relative pitch, hopefully.

  7. Amazing! Will check this out tomorrow along with 16-bit stuff to test
  8. A bit unrelated to my own music, but this is something I always wanted to see this one visualised from real hardware, thanks to Bayusumardi for the visualisation using my recorded audio This was why I was hacking Instrumentarium yesterday, since I edited the module inside of it, I had to change some code to have the Two-Tone Filter work where it was expected, and now I know how to manipulate it too, so that could be useful sometime for future projects. I wanted to record single audio channels, and had to adjust the code in question to not break everything as a result. I attached my hacked files in the post if anyone is interested, I have a lot of respect for the work behind this, so I wanted to learn from all of this, too! The reason why there is a ominous note playing 1 second before everything in all channels was purely for timing and synchronisation purpose, that's the method I always use when I record audio off hardware and want to get very constant results. Funnily enough only a moment ago I found out actually Analmux explained all that stuff in that thread: It would have saved me some time yesterday, but I feel pretty happy to know that even with no past experience in 6502 machine language, I figured it out on my own and got it working anyway, There's so many things I want to experiment with, it's all really exciting stuff. Instrumentarium Hack for Oscilloscope.zip
  9. I would like to mention there's still a lot of stuff I have yet to fully understand in all of this, and many errors I could try to improve, as well as some compromises that could work better too. Some things do sound better with my tuning, and some also sounds a little less good, there can only be so much possible with a limited pitch resolution For example, I know very well that G notes are out of tune, especially on octave 5, since there was so much to compromise, so it was either, be much lower and sound wrong, or higher and also sound wrong, I picked the option that sounded the most acceptable to me. That's one of the few notes that caused me problems. I think of the sharps especially, due to what was mentioned earlier. I'll link my most recent .txt file below, there will be some very clear examples of compromises, contradictions and many hesitations, so of course, a lot of improvements has yet to be done. Here's an example of this kind of mess: C-4 == (263.94) == 77 == 266.3 --- 79 == 262.0??? nah C#4 == (279.64) == 71 == 280.4 D-4 == (296.27) == 6B == 295.9 ok D#4 == (313.88) == 65 == 313.3 E-4 == (332.55) == 5F == 332.9 ok F-4 == (352.32) == 59 == 355.1 F#4 == (373.27) == 55 == 371.6 G-4 == (395.47) == 50 == 394.6 ok G#4 == (418.99) == 4B == 420.5 ok A-4 == (443.90) == 47 == 443.9 --- reference value for current tuning --- A#4 == (470.30) == 43 == 470.0 ok B-4 == (498.26) == 3F == 499.4 ok C-5 == (527.89) == 3B == 532.7 --- 3C == 523.9??? nah C#5 == (559.28) == 38 == 560.7 C-5 there, was literally out of tune from the intention I had at first, so I had to pick a compromise, and adjusted as many notes as possible to still sound good with the others, but that comes at the cost of potentially making even more notes sound wrong... So yeah, it's a long puzzle, but I admit I'm that kind of nerd to have fun in this, it's all math, in a way, hahaha In theory it's also possible to get as close as possible to 12-ET using 443.9hz as a reference to A, this was my initial approach, but the number of notes that got bad were a little annoying... which was what lead me to tune several things based on interval instead, and pray that most things work well together. And it does, somewhat, work okay, for the most part. But some tunes are likely to sound off, and that's partially my fault for the tuning, and mostly due to the limitation in pitches, same for distortion basses, a couple notes were pretty questionable compromises but worked okay as well. In fact in my own (messy) notes complete with frequencies in hertz and my own comments, can give a good clue about how much compromises I faced so far. There's also the "theoretical" frequencies I put as a reference in parantheses... it's actually just what if everything was 12-ET based on 443.9, and to my surprise. It turns out the same tables also worked really well in PAL for being closer to 440, so there's some good surprises at least Anyway, there's always room for improvements, hopefully I would say 1 or 2 tables aren't enough for this kind of situation. Like Ivo said, there will be keys that will work well in my tuning, and some that will most likely work fine, but sound... a tiny bit odd, or out of tune at worst, not that this cannot be done on purpose too! There was some tunes I had tested and those got a new layer of harmonisation, or even dissonance, and sounded great that way, so we never know POKEY Table 1.79mhz (Octave Pattern, Distortion C 1.79mhz) v1.txt
  10. Ow, sorry to know things broke like this. I did indeed use a mix of custom and regular RMT stuff in the tune, because some cases needed it and some didn't I personally like that behaviour, if a custom instrument entry is present: use the custom crafty data in the file, else it simply works exactly like originally coded. That works pretty well for me For what you mentioned above, yeah, that's what I meant to say, to simply mimick the way RMT handled 16-bit with the custom entries, I am not sure exactly how it behaves as I have not 100% experimented with it, but either way I know something will work out anyway, and like I mentioned in my more rambly part of the post, I still have many ideas I wanted to experiment with so don't worry about what I said, it will make sense... sometime when I get to try something new, or old Analmux's experiments are for example a great source of inspiration, emkay's cryptic posts also give me good clues for many things, and there's several ideas I have yet to try out on my own, also inspired by synthpopalooza's own impossible sounds, hahaa
  11. I've already calculated most of the Distortion C pitches, as well as other modes I tuned so far in my notes if you are interested. Maybe not the most accurate measurement but I think it's good enough to know what frequencies they really are. There's still a lot to polish and revisit but it's pretty usable for now I think! This would be incredibly useful for the approach I took for my frequencies tables, especially.
  12. Learned some very rudimentary 6502 code today lol
    Somewhat the necessity to achieve something makes you learn out of guesswork XD

    1. Jinroh

      Jinroh

      Righteous. :3 Congrats on your first steps in a new journey! The 6502 is lovely! ❤️

       

  13. Silly cat 

    IMG_20210410_171813.jpg

    1. Kiwi

      Kiwi

      ...Trix is for rabbits.

  14. I think it would be a good idea to use the 6th one for both cases, so it will still be the one used by default, as expected, and the 6th slot wouldn't need to be changed since it would have been assigned to Distortion 6 anyway. That would then leave every other slots follow the same order, and land on the matching number used in the 8-bit tables. In my opinion, that would work the best, considering how 8-bit had already been moved around and is 100% confirmed to work as expected by following the same order used in the tracker itself. That would make 16-bit do exactly what is expected as well when 16-bit is enabled, or it will simply use the matching 8-bit tables when not. Do you think it would be possible to add a certain form of individual instrument check, now that I think of it? Something such as: "if, and only if, instrumentXX uses AUDCTL bits for 16-bit ($50 for channel 2 output or $28 for channel 4 output), then 16-bit tables get used, else use the 8-bit tables like normal" I'm not sure if it's already the case but I'm asking anyway 😛 That could save a lot of potential issues if conflicting settings happen to be used at the same time, for example: "1 channel has an instrument at 1.79mhz (or not), and another channel has an instrument using "Join x+x", playing on the same row, they could be using different tables for different purposes, while still "technically" output 16-bit sound" This one case is a bit interesting, because that would make possible certain effects currently disabled in RMT when 16-bit sound (Distortion 6, specifically) is output, such as vibrato or portamento, where one channel handles most of the fine tuning and the other does most of the global note output. The downside would be the requirement of 2 different 8-bit tables, but once they (eventually) exist as 16-bit tables, it shouldn't be difficult to copy and paste elsewhere... I was able to prove it is possible to do in some of my test tunes... Tables truly are a blessing to have since you don't have to manually set the frequencies in the tracker every time, the same situation applies to the Sawtooth waveform I used recently, except that one was a "use 2 different 8 bit tables" situation, no 16-bit was necessary Does that even make any sense? lol, sorry if not, I'm rambling once more about "what could possibly work", hahahaha 🥴 I'm still really amazed how well the customnotestables.txt + custominstrument.erti system works so far by the way, you have my respects for making a lot of POKEY music making better 🍻
×
×
  • Create New...