Saturday, June 7, 2014

freeaudio streaming

or grrr bloody hell, old code should just work

The design of FreeAudio is based on limitless numbers of channel buffers being multiplexed by a very fast and simple accumulator with per sample rate and amplitude modulation.

Yesterday I failed to run some old code that wrote sample buffers during program execution.

Blitz audio is traditionally sound oriented, which is something that represents the channel that has been chosen from a limited pool, to be allocated to play your sample, which can then be modulated, or is that the channel? I always get a bit confused...


And not a few hours or is that days later on a Tuesday evening without a click on either win32 or macos the first release of freestream is ready.

' freestream.bmx
' mono 8 bit streaming example for 

Import pub.freeaudio
Const FRAG=1024
Print "freestream is free streaming..."
fa_Init(0) ' brl.freefreeaudio usually does this
Local buffer:Byte[FRAG*8]
Local writepos
Local sound
Local channel
Print "Sound:"+sound
Print "PlaySound:"+channel

Local streaming
Local lfo#
Local osc1#

While True
' Print "Status:"+fa_ChannelStatus( channel ) 
 Local readpos=fa_ChannelPosition( channel )
 Local write=readpos+FRAG*4-writepos
 Local frags=write/FRAG 
 While frags>0 
  Print "Write to "+writepos
  Local pos=writepos Mod (FRAG*8)
  For Local f=0 Until frag    
   Local t=writepos+f 
 If Not streaming And writepos>=FRAG*4
  fa_SetChannelPaused( channel, False )
 Print "." 

 Delay 50

The variable lfo refers to a low frequency oscillator, as BlitzMax is using degrees here the multiplier .001 is effectively 1 thousandth of a degree per 1/44100 seconds the suspected hz is ummm, errr... it seems to be oscillating at 5 seconds...

Latest version can be found here

Friday, June 6, 2014

webmidi 9.3 not working in Chrome

It is kind of bullshit source, I should have smelt a rat. so Chrome doesn't conform to basic ins and outs and the code here fails:

The example in section 9.3 is a bit shint, surely an ecma map like Chrome returns is better, whats with the odd looking containers and the abuse of the for in operator w3?

As for working code, Chrome likes the following better (with obligatory web midi enable in chrome:\\flags)

function enumMidiAccess( midiAccess ) {
 var inputs=midiAccess.inputs(); 
 for(var key in inputs) 
  var input=inputs[key];
  console.log( "Input port " + );

 var outputs=midiAccess.outputs();
 for(var key in outputs)
  var output=outputs[key];
  console.log( "Output port " + );

Google+ Chrome webmidi pre-announce

Monday, June 2, 2014

nsynth site update


homebrew holidays

The node based game server that starts and stops at is nearing 12 months old but the client code feels kind of new

There is a bug in portrait mode on my phone with an ominous button called Execute instead of my nice vector font terminal

[ All fixed in latest MonkeyX Release ]

The ping test bounces the same request, from Auckland to Sydney I am getting ~65ms turn arounds in chrome where as a standard icmp ping from the command line is reporting 34ms so research required....

the chat system is a simple relay running on a 1 hz refresh 

the shell login ignores everything you send it with a reply reporting the request headers

Client Side

The new Android monitor has no problem profiling the monkey game running on my ancient Ideos X5.

Replacing a glyph map with an array and the following keeps us happy, although ping is horrible compared to desktop. Hopefully a solvable issue.


Swerver Side

To keep the ping numbers honest we need 3 servers, Sydney, Virginia and Dublin.

Two new instances of my server are running and testing has begun.




Nearly enough IT for one day...