writing on this bytes container i thought
it could be fun to run a code that plays
array of shorts as 22100Hz audio, (1 channel, 16 bit)

(winanpi has functions for this: waveOut)

i load the vav onto screen when given 16bit
value i draw as a pixel so i got the sound drawed
(as blue-green mess)

44k hz sound better (22k souns a bit like from
casette recorder) but 22k makes more sound to seen
on screen (like 20 seconds instead of 10 seconds)

than i run the playback just from teh screen data
so i can play bitmap data like sorta of bitmap
gramophone (hovever playing bitmaps genarally makes
mostly if not ony some buzzes not much interesting)

so i decided to generate waves (using sin() ) into that
bitmap wav thinking if i divide given second of
playback onto 50 parts of 0.02 second each and if i
generate sinvaves based on a plot w ill draw with a mouse
(1 pixel y distance from bottom of screen = pitch of
20ms fragment that is playbacking) then i should obtain
something interesting (in theory coz in practice
it rather sounds like f1 8-bit bolid speeding engines up
and down)

the question is how to exactly generate those sinvaves
based the plot

right now i got something like (which is probably crap)
(but its total draft writing at the night as a series
of experminets with brain off) (thats why one need
to slow down and rethink it slowly)

int wave_pos =0;

void buffer_add_sinwave(int len, float a, int cycle)
{
for(int i=wave_pos; i<wave_pos+len; i++)
{
if(i>big_ofscreen_buffer_size_x*big_ofscreen_buffer_size_y) continue;

float t = (i%cycle)*1./cycle;
float s = sin(2*3.14159*t);
// float w = (s+1.001)/2.01;
w=s;
unsigned int val=a*(127*256*w);
big_ofscreen_buffer[i] = val;//+rand()%5;
}

wave_pos+=len;

return;
///////////////////////////////////////
}

int tempo = 22050/44.1;

float volume = 0.3;
int base = 22050/1;

void buffer_add_sinwaves()
{

wave_pos =0;
for(int i=0; i<floats_size;i++)
buffer_add_sinwave(tempo, floats2[i]/frame_size_y, base/floats[i]);
}

two notes
1) i dont in fack know what those 16 bit walues are, they are
unsigned or signed
2) here the frequency it semms i generate cycle (of sinvavw) = 22khz/y
which means for y = 10 i got 2200 pixels wave so its 10 hz
for y=100 i 220 wave - so its 100 hz ?

(i get a little bit (i mean uch) tired of this but it
overally seems somewhat interesting)

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: i2pn2 (i2pn.org) (3:633/280.2@fidonet)

fir wrote:

than i run the playback just from teh screen data
so i can play bitmap data like sorta of bitmap
gramophone (hovever playing bitmaps genarally makes
mostly if not ony some buzzes not much interesting)

i mean normal graphical bitmaps sound like buzzes
whan those that are generated from loaded vaw - it is those
who are mess soound like music

so regular imeges give buzes but mess images give music

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: i2pn2 (i2pn.org) (3:633/280.2@fidonet)

fir wrote:

fir wrote:

than i run the playback just from teh screen data
so i can play bitmap data like sorta of bitmap
gramophone (hovever playing bitmaps genarally makes
mostly if not ony some buzzes not much interesting)

i mean normal graphical bitmaps sound like buzzes
whan those that are generated from loaded vaw - it is those
who are mess soound like music

so regular imeges give buzes but mess images give music

some things showed imo

1) the vaves seem to be 16 bit signed, so drawing it as a bitmap
not fully works cos -min and +max have nearly the same color on screen
(0x8000 is lowest 0x7fff is max)where 0 sound and -1 sound have quite different colors 0x0000 and 0xffff) - but at least it seems i generati
it right (?)

unsigned short val=amplitude*127*256*sin(t);

i rewritten the code

void buffer_add_sinwave(int len, float amplitude, float hz)
{
for(int i=wave_pos; i<wave_pos+len; i++)
{
if(i>big_ofscreen_buffer_size_x*big_ofscreen_buffer_size_y) continue;

float cycle = 22050.0/hz;
float t = 2*M_PI*fmod(i,cycle)/cycle;
unsigned short val=amplitude*127*256*sin(t);
big_ofscreen_buffer[i] = val;
}
wave_pos+=len;
return;
}

but there seem to be a problem with high frequenzy at all
and i seem not to understand something

if 20.1 khz is 20100 pixels per second (send to waveOut which is set to
take 20.1khz 16 bit 1 channel) then how i can draw 20.1 khz when
one 'period' 'wave' is 1 pixel ? it seems i could draw at most 10.06 khz
az tost when one wave will be then 2 pixels width - hovever if i draw it
it seem al sound a lot higher

this overally might mean i should possibly sqwitch to 44.2 khz or even more
to ba able to draw 22 kh with 2 pixels or more

istnt it?
(i know maybe nobody here was doing such lowlewel audio but i post it
becouse it seem generally lowlewel in interestuing - and c is big part
about lowlewel imo)




--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: i2pn2 (i2pn.org) (3:633/280.2@fidonet)

On Tue, 02 Apr 2024 14:29:17 +0200
fir <fir@grunge.pl> wrote:

fir wrote:

fir wrote:

than i run the playback just from teh screen data
so i can play bitmap data like sorta of bitmap
gramophone (hovever playing bitmaps genarally makes
mostly if not ony some buzzes not much interesting)

i mean normal graphical bitmaps sound like buzzes
whan those that are generated from loaded vaw - it is those
who are mess soound like music

so regular imeges give buzes but mess images give music

some things showed imo

1) the vaves seem to be 16 bit signed, so drawing it as a bitmap
not fully works cos -min and +max have nearly the same color on screen
(0x8000 is lowest 0x7fff is max)where 0 sound and -1 sound have quite different colors 0x0000 and 0xffff) - but at least it seems i generati
it right (?)

unsigned short val=amplitude*127*256*sin(t);

i rewritten the code

void buffer_add_sinwave(int len, float amplitude, float hz)
{
for(int i=wave_pos; i<wave_pos+len; i++)
{
if(i>big_ofscreen_buffer_size_x*big_ofscreen_buffer_size_y) continue;

Shouldn't this be break ? When i>big_ofscreen_buffer_size_x*big_ofscreen_buffer_size_y , it will remain
true for all the other values of i in the loop.

float cycle = 22050.0/hz;
float t = 2*M_PI*fmod(i,cycle)/cycle;
unsigned short val=amplitude*127*256*sin(t);
big_ofscreen_buffer[i] = val;
}
wave_pos+=len;
return;
}

Are big_ofscreen_buffer , big_ofscreen_buffer_size_x , big_ofscreen_buffer_size_y
global variables ?

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

Spiros Bousbouras wrote:

On Tue, 02 Apr 2024 14:29:17 +0200
fir <fir@grunge.pl> wrote:

fir wrote:

fir wrote:

than i run the playback just from teh screen data
so i can play bitmap data like sorta of bitmap
gramophone (hovever playing bitmaps genarally makes
mostly if not ony some buzzes not much interesting)

i mean normal graphical bitmaps sound like buzzes
whan those that are generated from loaded vaw - it is those
who are mess soound like music

so regular imeges give buzes but mess images give music

some things showed imo

1) the vaves seem to be 16 bit signed, so drawing it as a bitmap
not fully works cos -min and +max have nearly the same color on screen
(0x8000 is lowest 0x7fff is max)where 0 sound and -1 sound have quite
different colors 0x0000 and 0xffff) - but at least it seems i generati
it right (?)

unsigned short val=amplitude*127*256*sin(t);

i rewritten the code

void buffer_add_sinwave(int len, float amplitude, float hz)
{
for(int i=wave_pos; i<wave_pos+len; i++)
{
if(i>big_ofscreen_buffer_size_x*big_ofscreen_buffer_size_y)
continue;

Shouldn't this be break ? When i>big_ofscreen_buffer_size_x*big_ofscreen_buffer_size_y , it will remain true for all the other values of i in the loop.

float cycle = 22050.0/hz;
float t = 2*M_PI*fmod(i,cycle)/cycle;
unsigned short val=amplitude*127*256*sin(t);
big_ofscreen_buffer[i] = val;
}
wave_pos+=len;
return;
}

Are big_ofscreen_buffer , big_ofscreen_buffer_size_x , big_ofscreen_buffer_size_y
global variables ?

yes, what people call it, (coz it is not global but module scope
(exe/dll) in fact)
thsi name is bad should be offscreen buffer but when i code various experiments i dont care for names to much (than in normal 'design' code)

--- MBSE BBS v1.0.8.4 (Linux-x86_64)
* Origin: i2pn2 (i2pn.org) (3:633/280.2@fidonet)