Jump to content
PacManPlus

What do you guys use to create Pokey Music?

Recommended Posts

I'm curious, by the sounds of it, once or twice per frame seems ample enough for a program as good as RMT to use to create numerous instruments, but knowing that DIGI sounds & synthesized sounds require much quicker updating, could (or does) RMT or any music program in general (if created) allow DIGI instruments, as, if you combine your regular instruments in the same package as creating DIGI instruments to run faster than the rest of the music piece, ie. all usual instruments run once or twice per frame, but when DIGI instruments are detected update them more often, perhaps, about 5 times or more per frame.

MPT supports samples in music (but IIRC it cannot play them in different pitches, just replays what you throw at it at a default frequency). But it's a native Atari tracker. So far there's no cross-platform POKEY tracker to support samples.

Share this post


Link to post
Share on other sites

I want to know how this was created. It's still IMHO the best overall music on the Atari.

 

https://www.youtube.com/watch?v=qfo-tUHP7_o

Ofcourse, this one is great. No question.

You can notice that the "drums" were a little noisy but clean. They were that low in CPU usage that the animations were still possible. Together with sound generator it builds a nice "allover sound-picture" . The wave shaping as used in my demontrations would take only some CPU cycles more, here and there, for correcting the start of a soundwave.

The problem with POKEY is still to have clean low sounds: Drums and Basses. Digitizing the low sounds also solves problems with the volume and channel mixing.

Well, a PC Tool like RMT with real 16 Bit support and a digichannel for deep notes would be TEH TOOL ;)

Share this post


Link to post
Share on other sites

Technically the best one is this:

 

 

This is the most advanced Soundengine, using POKEY generators and Digis for Drums and FX... even some voice.

 

But they didn't know about the waveshaping and adopted the notes directly from the C64 to the Atari, without correcting all necessary parts.

 

Imagine the synth sounds of "my" experiments, PLUS the digis. That'S the way to go ...

Edited by emkay

Share this post


Link to post
Share on other sites

I want to know how this was created. It's still IMHO the best overall music on the Atari.

 

There was no tracker involved in the making of this tune. Just honest toil in assembler.

Share this post


Link to post
Share on other sites

The pokey can certainly also benefit from the frodigi method (I have read a brief outline of possibilities) and it certainly has potential, many of which seem unexplored.

By the way I have released the third version of frodigi on c64 (finally reducing the "clicking" by certain methods as well as the encoder attempting to preserve the bassline more accurately.

 

http://www.youtube.com/watch?v=DFteV6YE7F0

  • Like 3

Share this post


Link to post
Share on other sites

It wont be released. There are many people negatively talking about the method (but probably wishing inside that they can use it to their advantage) So no, no sources or executables :-| Its not a complex process anyhow

Share this post


Link to post
Share on other sites

It wont be released. There are many people negatively talking about the method (but probably wishing inside that they can use it to their advantage) So no, no sources or executables :-| Its not a complex process anyhow

That's a pity. I think your approach is a very smart way to do samples on limited hardware. I would like to hear how would POKEY handle it :-)

Moreover, this method could be used for digitized ingame sound effects without heavily loading the CPU.

Edited by pseudografx
  • Like 1

Share this post


Link to post
Share on other sites

It wont be released. There are many people negatively talking about the method

Negativity in the retro computing scene.. surely not :P

 

The pokey can certainly also benefit from the frodigi method (I have read a brief outline of possibilities) and it certainly has potential, many of which seem unexplored.

I've also been interested in the possibilities of your method when it was brought up and discussed briefly at fwar. I was hoping you were going to discuss it further but I can understand the reasons not to.

  • Like 1

Share this post


Link to post
Share on other sites

Well to cut a long story short, There are certain individuals/groups who critisise the video / audio compression methods (e.g csam super, frodigi) and when i decide to release the encoder (csam super) these people who tend to have acted negatively end up using it in their demo's.

 

I also have never claimed that the quality is good (After all, what can be expected attempting to cram in drums, bassline, singing, lead and other audio data into 3 sid channels using just the 4 waveforms at 1 frame per second) Its rather more a tech demo to showcase what can be produced with the encoder.

 

Wont mention any names, but i guess those that complain about the quality are those that attempted something similar but failed miserably :-)

 

 

Hence any encoder that i produce will be kept to myself from now on (Although will keep on releasing demo's)

 

If anyone is interested in how it works, i have given some brief information in pouet or csdb

 

http://csdb.dk/release/?id=133293&show=notes#notes

Share this post


Link to post
Share on other sites

Pity if you choose not to release it. Impressive results for the given amount of data used.

How it would translate to Atari though, unknown. The available triangle/saw frequencies that are useful don't cover a great deal of range. Possibly the whole thing could be done in an emulation sort of way with the added CPU cost.

But irrespective of that, anything that could give equivalence to existing packed raw data that takes 2-4K per second or more in a fraction of that space is well worth having.

Share this post


Link to post
Share on other sites

FroDIGI is a nice approach ... btw. but...

It wouldn't make sense, to have that converter available for a development base on the Atari.

 

Not sure , what people believe. SID is done to have "linear" commands for acting on programming. It's the same with the graphics. That's why it takes that long, to have people understood, how it works.

Programming POKEY is a full different kind of handling (compared to SID) , and the source, you have to produce will also have nothing in common with the "pre calculations" for the SID's registers.

Share this post


Link to post
Share on other sites

The pokey can certainly also benefit from the frodigi method (I have read a brief outline of possibilities) and it certainly has potential, many of which seem unexplored.

 

 

Quite interesting! I also built a somewhat similar converter for Pokey some years ago, unfinished - but basically working.

It uses the SA_POKEY.DLL and feeds it with permutations of control values, analyzing the output statistically.

The source audio is handled the same way (frame wise) and the similarity mapping outputs the control values.

 

Is there really demand for such converter?

  • Like 2

Share this post


Link to post
Share on other sites

 

Quite interesting! I also built a somewhat similar converter for Pokey some years ago, unfinished - but basically working.

It uses the SA_POKEY.DLL and feeds it with permutations of control values, analyzing the output statistically.

The source audio is handled the same way (frame wise) and the similarity mapping outputs the control values.

 

Is there really demand for such converter?

 

Sounds awesome! I would love to see what you've got!

Share this post


Link to post
Share on other sites

 

Quite interesting! I also built a somewhat similar converter for Pokey some years ago, unfinished - but basically working.

It uses the SA_POKEY.DLL and feeds it with permutations of control values, analyzing the output statistically.

The source audio is handled the same way (frame wise) and the similarity mapping outputs the control values.

 

Is there really demand for such converter?

 

I believe if you could increase the quality by using more updates per frame (4, 8..) it could be very interesting.

 

Something like a rastaconverter but for sounds and music..

Share this post


Link to post
Share on other sites

Sounds awesome! I would love to see what you've got!

The problem with that DLL is the wrong sound handling. It's not only that it doesn't really sound like POKEY, it also produces artefacts than POKEY doesn't . Which means, at the end you get results that haven't anything in common with the original hardware.

Share this post


Link to post
Share on other sites

The problem with that DLL is the wrong sound handling. It's not only that it doesn't really sound like POKEY, it also produces artefacts than POKEY doesn't . Which means, at the end you get results that haven't anything in common with the original hardware.

But it could lead to software running on the Atari, which will sound correct :)

Share this post


Link to post
Share on other sites

 

I believe if you could increase the quality by using more updates per frame (4, 8..) it could be very interesting.

 

Something like a rastaconverter but for sounds and music..

 

In its current implementation, increasing to more than one update per frame results in more distortion. This is due to the oscillators being "free running" The encoder can find a good match based on the offset of the amplitude but in reality the oscillator can be at any amplitude on the next update.

 

Its more a catch 22 situation. Emulating the current oscillator position (of where it would be in the decoder) would result in less "optimum matches" but also less distortion. While opting for the free running method would give more potential matches (but more distortion if updating more than once per frame). This applies to methods where more than one channel is used to reproduce the sample (and in particular sawtooth waveform where a rising section in the wrong phase in the decode can destroy the reproduction quite a bit)

 

In regards to rastaconverter. The frodigi's hill climbing works very much like it with data being fed into the virtual ear but then also adjusted via genetic methods. I am using a variant of the hill climbing method known as step count hill climb which can reduce local minima issues more than late acceptance hill climbing in most cases.

  • Like 1

Share this post


Link to post
Share on other sites

Tezz... can you have a look at the c64 demos and "patch it" for a first run on A8 though? :)

 

I thought A8 scene is "negative" ;) but the c64??? :D no honestly... would not care much about the others...

 

Rastaconverter for Sound "sounds" cool...

Edited by Heaven/TQA

Share this post


Link to post
Share on other sites

Rastaconverter for Sound "sounds" cool...

Well, the deepest and clean sounds, you get , using 1.79MHz filter.

Based on the fact that you hear the "interference sidesound" , you can form that with self modulating waves. Forward and backward pulses, repetitive pulses... and so on. This is, what SID is in no way able to do. And the best thing: POKEY is always finishing a started wave, so you won't get any sidenoise there ... Think about it. At the end you get an "analog characterized" (because waves get created at 3.5MHz - it will sound "analog" to you....) wave with approx. 2 VBI Cycles ... from digitized data.

Share this post


Link to post
Share on other sites

Tezz... can you have a look at the c64 demos and "patch it" for a first run on A8 though? :)

 

I thought A8 scene is "negative" ;) but the c64??? :D no honestly... would not care much about the others...

 

Rastaconverter for Sound "sounds" cool...

It'll be interesting to go through the demos this evening and figure things out.

Share this post


Link to post
Share on other sites

MPT supports samples in music (but IIRC it cannot play them in different pitches, just replays what you throw at it at a default frequency). But it's a native Atari tracker. So far there's no cross-platform POKEY tracker to support samples.

It supports different pitches when using two digi-voices (one voice has it though, the other is for drums). For example my Too Hard Matter.

Edited by miker
  • Like 2

Share this post


Link to post
Share on other sites

It supports different pitches when using two digi-voices (one voice has it though, the other is for drums). For example my Too Hard Matter.

Thanks for correcting me. It's been a long time since I last used MPT, so I don't remember the features so well.

Share this post


Link to post
Share on other sites

Moreover. MPT has editable frequency tables (well, at least 8-bit ones - 4 of them in total). And all of them are saves together with music. Here's old example of my experiments with triangle waves (still not supported by SAP players!):

 

 

On real stuff it sounds even better! :)

Edited by miker

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...