Page 3 of 5

Posted: Fri Dec 04, 2009 6:23 pm
by Twilighte
Hi Carlsson, quite a lengthy response..
carlsson wrote:Most known sound chips will produce a sound relative to frequency. A low value gives a low frequency, a high value gives a high frequency.
Unfortunately this is just not true..
The AY pitch value is the opposite. Low pitch values correspond to higher frequencies and high pitch values correspond to lower frequencies. In fact in my experience of most Sound chips (SID, AY, SN76489(BBC)) operate like this.
This is due to the mechanics in producing the sound in the first place.

The basis of all sound generation for these chips is taken from the input clock frequency. The internal curcuitry divides down the clock using counters so that the lower counter values will timeout more often and invert the output. The counter is like the 6522 timers. They always run at the clock frequency but are programmable to the number of counts.

A good example is with the AY when compared to the Spectrum 128 and Atari ST. The Spectrum drives the AY with a clock frequency of half the cpu speed which equates to around 1.7Mhz. The Atari drives it with a 2Mhz clock. Because of this any music expected to run on both machines must be tuned differently (using two very different note tables). Furthermore the Hardware envelope periods will also be different.

Anyway, back to your 'article'..
carlsson wrote: As we have seen, the delta frequency between two octaves are fewer Hz the higher note we want to play. It will be reflected in the sound chip as each value will yield an increasingly higher frequency. We get poor note resolution at the upper end, music sounds detuned. The bigger range of possible values, the better resolution. For example the SID chip uses 16-bit values which gives it quite good note resolution.
Hmm, i partly agree except if you hear the sid tunes i did some years ago (these are the same C64 code running on an Oric with the SID output translated into AY pitches) sound pretty much the same in pitch resolution as the C64 original.

Moving down a lot further..
carlsson wrote:I hope this lengthy message explains what I meant. All of this is theoretical and has no real point in the discussion. I just wanted to point out that poor note resolution in the upper octaves is not unexpected, given on what premises the sound chips actually produce sounds. :-D
It does explain what you meant but i don't see what bearing it has to the real world. Most sound chips have log pitch because of the mechanism explained above. Unless i have got it wrong (which i have many times) and the majority of sound chips are based on a well tempered scale.

Admittedly a bigger resolution of pitches does give the possibility of higher notes being better represented, but i have not really noticed this.

The Orics AY is capable of producing frequencies from 15.26Hz to 62.5Khz (Refer AUG Page 47). If wikipedia is to be relied on The human ear is limited to a range between 20Hz and 20Khz so the Oric is more than capable to satisfy this range.

In fact our very own beloved Oric Atmos (black one) manual says on page 106 that pitch values below 5 attract Dogs!!

Interestingly the world famous SID chip is actually only capable of producing a fraction of the Oric AY's frequency range. The SIDs range (source from wikipedia) is from 16 to 4000 Hz.

However going back to your article i do agree that a smaller range of values between semitones is not such a hindrence as thought. Even limited to 3 or 4 values between, a pitchbend may still sound smooth when swept across a long range. However Vibrato is best based on this interpolation of semitones rather than the conventional direct modification of the pitch. However Wave does not do this because if it did it would slow the process too much.

Thinking about it, it is possible to optimise the interpolation for speed by using a precision table of 4 or 8 points between semitones (using your 256 byte idea) but since the AY pitch is 12 bit thats 512 Bytes which i do not posess in the current version of wave to spare :P
Anyway even computing the figures is not too cpu intensive and does permit the resolution to be set within the music.

However an interesting article Carlsson, one that has stimulated my thoughts, thanks.

Posted: Fri Dec 04, 2009 8:31 pm
by carlsson
I can't speak for the AY and SN chips, but I'm absolutely sure $0001 makes SID produce its lowest frequency and $xFFF (can't remember the value of x) makes a very high pitched sound.

Perhaps you're thinking about the actual frequency of a note which works like you describe: at 50 Hz you get a very low bass note but at 10 kHz you get a very high one.

Posted: Sat Dec 05, 2009 11:43 am
by Twilighte
ok, just checked with C64 geek friend and you are right, C64 SID does work the way you say. However i do know for the AY and SN..

For AY i do know, i've been dealing with the beast for 25 odd years.
For SN it works like AY using a divider curcuit (Source Wikipedia)

Posted: Tue Dec 08, 2009 1:12 pm
by carlsson
It seems the Commodore chips are the odd beasts in this way:

Low value = low frequency
VIC-I (VIC-20), SID (C64/128), TED (C16 and Plus/4)

Low value = high frequency
AY, SN and POKEY (Atari)

See for example this document on basic POKEY programming:

In practise it is only a matter of semantics once you got your way around it, but it amazes me how General Instruments, Texas Instruments and Atari all chose the same "programming interface" (for lack of better word) but Commodore starting with the VIC-I went the other way around.

I don't know which other chips are worth comparing.. what makes noise in the NES for example?

Posted: Wed Dec 09, 2009 5:09 pm
by Twilighte
Personally i don't see the merit of comparing Sound chip hardware in this regard, it is simply the way they behave. It would be like comparing Z80 to 6502 or ULA's. Anyway i'd also appreciate it that if you do pursue the line of thought you do so in a new forum thread rather than this one which is related to Wave, no offence intended.

SID sound now pretty much works 100% however i did notice that if SID Noise is used with the Tone channel switched off no output is heard even though volume is set high.
Also added a command to duplicate the current pattern to a new unused Pattern (not in List) and focus on that.. This has proved invaluable so far.

I must now get to work on modifcations to the compiler and player for this next version of Wave :P

Posted: Wed Dec 09, 2009 11:49 pm
by Twilighte
For a while now i've been thinking why most trackers have patterns organised like WAVE and not like i did in Sonix? In Sonix Patterns for each channel where taken from a separate 'pot'. In later version Patterns for each channel where taken from a single 'pot'.
However with WAVE and most other trackers on other platforms a pattern includes all three channels. This is not as efficient as my Sonix way of doing it however it does encourage any tune to be taylor made throughout and i think thats the point.
I don't feel resistant anymore to change part of a pattern incase it was used in other areas of the music, which means we get a much more detailed and taylor made piece of music.

However it does mean music composed on Wave will tend to be shorter and is unlikely to be like the 25 minute Magnetix tunes of old :/

Posted: Fri Dec 18, 2009 11:26 am
by Twilighte
Started work on a Sample Compiler for Wave. It allows one to select up to 7 samples from a library of about 180.
The 180 samples vary from Python vocals to Drums and from Star Trek sfx to Instruments.

Additional samples may be imported but not done this yet. The utility will generate a Sample Block file that can be loaded directly into WAVE.
The utility will also allow the Sample to be played and doubled in pitch (Half length).

The utility is about 50% complete and will be selected from the WAVE main menu.

Posted: Fri Dec 18, 2009 1:10 pm
by ibisum
This is really becoming quite brilliant .. may I suggest that at some point in the future, we work on making MIDI possible on the Oric, so we can exploit all this new-found music-making prowess from afar .. ?


Posted: Sat Dec 19, 2009 11:49 am
by Twilighte
MIDI has been a long term ambition of many others to convert for use on the Oric. Unfortunately the format of MIDI and the format of WAVE make it difficult (but not impossible) to convert.

MIDI is event based whereas WAVE is tracker based,
MIDI has 16 potential channels whereas WAVE (and the Oric) has 3.
MIDI allows for independant timing of each channel whereas WAVE has a finite timing across 3 channels.

Personally i have no time to delve into the possibilities of converting midi file to oric for use in wave or other. However i can supply formats to anyone who so wishes to take on this formiddable project.

I know that in actual fact MIDI files have already been played on the Oric. I can't remember who but i'll try to dig out the oric disk and raise another forum thread regards it. If anyone else remembers please do same.

Posted: Sat Dec 19, 2009 12:14 pm
by Dbug
Was Fabrice who made the demo disk with midi musics

Posted: Sat Dec 19, 2009 3:16 pm
by Chema
Yes, Fabrice wrote a small midplayer. It had several limitations, though, so some midis did not sound correctly.

EDIT: Found it!

Posted: Mon Dec 21, 2009 12:42 pm
by ibisum
There are two aspects of MIDI, and usually only one is taken into account in such discussions:

a) as a file format


b) as a control protocol (realtime/live use)

What I was referring to was MIDI as a control interface - set up the Oric-1 as a synth, receiving MIDI control bytes, playing note-on/note-off messages and having some sort of custom parameter mapping to continuous-controller change (CC#) messages over MIDI. This would mean that the Oric becomes a real synth, and it can be used with a DAW/sequenced over MIDI for performance uses ..

It'd be easy to do, I've thought about doing it myself with my little fleet of Atmos's, but alas I have so many other nice projects to do and so little free time for such candy ..

Posted: Fri Jan 15, 2010 9:25 pm
by Twilighte
Currently (yes, at last Chema) working on the wave issue with bars in V1.0.

First mistake was in Compiler which assumes Bar will be the only event in a Bar Row (this is not always the case). So when compiling it searches the complete pattern row for a bar before compiling then adds a single bar to the pattern. This should also mean a slight reduction in the compiled music size.

Second mistake was with the way bars are detected in the player. It also assumes the bar may occur mid pattern row. Now it just looks for a bar then processes the next list row before executing the pattern row.
It means that on finding a bar it processes the first row of the next pattern.

So now no delay between patterns. However it still buggers around with ornaments mid song.. i am working to try to locate this issue. I am wondering it might be related to the way it stores Ornaments, but we shall see.

Posted: Fri Jan 15, 2010 9:36 pm
by Chema
Thanks Twilighte, hope you find the bug soon :)


Posted: Fri Jan 15, 2010 10:32 pm
by Twilighte
Chema wrote:Thanks Twilighte, hope you find the bug soon :)

Well i've actually found another bug, it seems every rest also stores a volume entry which wastes another byte. Hopefully this is not changes i've made for V2.0 Wave and you'll find even better compaction ratio.
Continueing to debug..