World: r3wp

snd: load http://krutek.info/rebol/sound.r

view layout [
	button "play" [
		wav: make sound [rate: 22050 data: snd] 
		print "make wav" ? wav
		sndport: open sound:// 
		insert sndport wav 
		print "insert sound" ? wav
		close sndport
	]
]

and look at debug output in console

wav does change after inserting into sound port

I really don't understand why

bug probably?

I've changed example from documentation to produce 16bit sound instead 
of 8bit

print "Play a simple tone..." ; (init event system too)

; Generate a sine wave tone (1 cycle of the wave):
tone: #{}
for phase 1 360 6 [
	val: 32768 + to-integer 32767 * sine phase

 repend tone [to char! to integer! val / 256 to char! to integer! 
 val // 256]
]

; Set up the sound sample parameters:
sample: make sound [
	rate: 44100
	channels: 1
	bits: 16
	volume: 0.5
	data: #{}
]

; Repeat the sine wave for 1000 cycles:
loop 1000 [append sample/data tone]

; Play the tone now:
? sample
sound-port: open sound://
insert sound-port sample
? sample
wait sound-port
close sound-port

it still changes resolution to 8bit and channels to 2

sound has a lot of problems:
the .wav data source is modified at loading

a low-q sample seems to force a permanent low-q to all successive 
samples

samples are adapted (=modified) to audio capabilities at first use, 
if 'rate or 'bits are not the default values.

the only way to play samples without these problems is to: 
- open the sound port
- insert a copy of the sample/sound object
- close the port
for each sound.

Yes, I have already found this "modification" problem.

IMO this modification - if it's needed - should be invisible to user

coz it's really confusing me

The modification keeps happening, if you play different samples alternately, 
each sample is modified randomly, converted to a random mode. Gradually 
the sample becomes noisy due to rounding errors in the conversions.

yes, it's modified randomly, I've done some test but the results 
were different all the time so I felt lost

This is a known issue. RT wants to address sound at some point, but 
I'm not sure where it falls in the priority queue.

Here an article that could be usefull someday
http://dafx04.na.infn.it/WebProc/Proc/P_201.pdf

By way of Christian's site

unfortunately there's missing page 2 in the document. however if 
anybody is interested in synthesis, next version of sintezar is going 
to have five different oscilators, four filters, three waveshapers 
(these units are ready now) plus some other units (phaser is ready, 
i'm working on delay). I wrote some basic sequencer last week, so 
only some preset management system is missing and some work on GUI 
(drag and drop for connecting modules is ready, but I still have 
to rewrite all modules to support it)

Sounds good Kru, would like to look at it when you're ready.

Antor if you're interested, here's a screenshot of work in progress 
- http://krutek.info/pix/sintezar.jpg

Very nice looking ! May I criticise your knobs though ? They are 
a bit big. Before long, you won't have any room left ! :) I suggest 
make them half the size in width and height.

But very good. Inspirational, indeed.

i love those fancy bars from winamp or wmp how they do that ? how 
they get the khz and hz and all that from the wav file ? suposing 
it is a wav ... (raw or pcm)

fast fourier transformation. no way in current rebol (to much computations). 
On my Athlon XP 1700+ can REBOL do some 3milions computations in 
second (this is very aproximate number, some computaions are more 
time-consuming than other ). May sound like a big number, but if 
sound's sample rate is 44100Hz, there's only some 70 computations 
for each sample. And this is the ideal situation (no GUI and other 
CPU-demanding stuff). So there are two possibilities. 1) Some faster 
math, or JIT REBOL compiler  and 2) wait for faster CPU's. Let's 
see what comes first.

(He he he....)

first comes faster CPUs :-) What about producing language extension? 
Ah, we did not get any yet, sorry, I forgot, it is long time we were 
promissed to get those ;-) Hmm, but what about external library calls? 
Could do the trick, no? If you use gcc, you should be able to compile 
for main platforms at least ...

JIT (VM) for some specific tasks could be sufficient too, but we 
can only hope here. The only realistical thing is to use what we 
have now - other tool than REBOL ;-), or library calls ....

Pekr yes, external library call can solve it (partially). I have 
to install some C/C++ SDK and start to learn it again...

I worked with image data in external library, was not all that difficult. 
Forget C ++, use C. But then - image data is just repetitive pattern 
of RGBA values, so maybe working with sound data will be much more 
difficult ...

Can you write prototype in rebol, and i try my c-skills?

sorry, what prototype?

Syntezar's?

that needed c-part, fft.

i don't know the math, but i may be able to translate rebol to c.

there's fft C library, http://www.fftw.org/

so you only need stubs?

but I haven't tried it yet.

No I probably have to rewrite all my routines to C. I haven't started 
working on FFT at all.

I've got phase-distortion oscillator, FM oscillator, wavetable oscillator 
and my exponential oscillaor plus four types of filters and it's 
really time consuming in REBOL

Can i try t translate that?

That should be great

Where to start?

you can try this Phase Distortion I wrote yesterday

where do i find it?

osc: context [
	phase: 0
	AM: 1				;Amplitude modulation
	PWM: 0.5		;Pulse width modulation
	DCW: .5	; phase transition between sine and other wave [0 - 1]

 wave-length: 400	;wave-length is sample-rate / frequency - don't 
 wanna have samplerate here	
	algorithms: [
		saw [
			d: (1 - dcw) / 2
			cosine 360 * switch-range ph [
				0 d [ph * (pwm / d)]
				d 1 [(ph - d / (1  - d)) * pwm + pwm]
			]
		]
		square [
			d: 1 / max 1e-50 (1 - dcw)
			cosine 360 * switch-range ph reduce [
				0 .25 [ph * 4 ** d / 4]
				.25 .5 [(abs ph - .5) * 4 ** d / 4 + .5]
				.5 .75 [ph * 4 - 2 ** d / 4 + .5]
				.75 1 [(abs ph - 1) * 4 ** d / 4 + 1]
			]
		]
				
		triangle [
		;triangle is d~.588888
			d: 1 - (dcw * .41111) ;1 / max 1e-50 (1 - dcw)
			cosine 360 * switch-range ph reduce [
				0 .25 [ph * 4 ** d / 4]
				.25 .5 [(abs ph - .5) * 4 ** d / 4 + .5]
				.5 .75 [ph * 4 - 2 ** d / 4 + .5]
				.75 1 [(abs ph - 1) * 4 ** d / 4 + 1]
			]
		]
	]
	algorithm: 'saw
	curves: copy []
	forskip algorithms 2 [append curves to string! algorithms/1]
	phaser: func [][
		phase-per-byte: 1 / wave-length
		phase: phase + phase-per-byte
		if phase > 1 [phase: phase - 1]
		phase
	]
	wave: func [
	][
		ph: phaser
		do select algorithms algorithm
	]

right here ')

Thats the right size to refresh my knowledge :)

PWM should be always 0.5 (it's from some older version)

it supprots three different waveform (still six missing to recreate 
my CasioCZ ;)

basics are 'phaser function - updates oscillator phase