Forum Replies Created
-
AuthorPosts
-
Have now added changes to common.sh and building modules slowly….
As this is just a fork of the main repo to use monkey2 on pi do following from the pi home folder:
git clone https://github.com/nitrologic/monkey2
cd monkey2/scripts
./updatemods
etc.
I was pretty proud of my BlitzMax collision implementation. It uses a pretty simple scan converter and allows use of layers that can be used to optimise collision performance further.
PortMIDI is desktop only.
A native mobilemidi module could share a common midi namespace with portmidi module so from Monkey2 app development the receiving / sending midi over OSC and bluetooth could be nice and simple.
As for timing, I plan to start running multiple processes per app. At present sharing the main thread with an SDL2 window rendering loop is not ideal.
On Android separation of render and gui threads is enforced so it will be interesting to see how SDL2 behaves in this environment.
Golly this sounds cool. Can’t wait!
Samples per frame is 44100/60 = 735 but typical audio buffers need to be power of two so I am thinking for simple ping pong buffers fragment size of 2048 should be safe bet for uninterrupted polling per OnRender.
How do Monkey2 timers work? Do they interrupt code or fire on app update?
I use a mutex to stay thread safe and it is up to monkey2 app to keep the buffer fill.
This is my current polling technique which I call every render:
Monkey1234567891011Method UpdateAudio()While TrueLocal buffered:=audioPipe.writePointer-audioPipe.readPointerIf buffered>=WriteAhead ExitLocal samples:=FragmentSizeLocal buffer:=vsynth.FillAudioBuffer(samples)Local pointer:=Varptr buffer[0]audioPipe.WriteSamples(pointer,samples*2)WendEndI have written following C++ class so vsynth.monkey2 can hopefully be thread safe.
It seems to be working and hooking up C++ to monkey2 felt pretty darn cool.
C++12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455#pragma once#include <deque>#include <mutex>typedef double Sample;class AudioPipe{std::mutex mutex;std::deque<Sample> buffer;public:int readPointer=0;int writePointer=0;void WriteSamples(Sample *samples,int count){mutex.lock();for(int i=0;i<count;i++){buffer.push_back(samples[i]);}writePointer+=count;mutex.unlock();}void readSamples(short *dest, int sampleCount){mutex.lock();int available=buffer.size();if (available>=sampleCount){for(int i=0;i<sampleCount;i++){Sample s=buffer.front();buffer.pop_front();dest[i]=32767*std::max(-1.0, std::min(s, 1.0));}readPointer+=sampleCount;}mutex.unlock();}static void Callback(void *a, unsigned char *b, int c){memset(b,0,c);auto pipe=(AudioPipe*)a;int sampleCount=c/2;short *dest=(short *)b;pipe->readSamples(dest,sampleCount);}void *Handle(){return (void *)this;}static AudioPipe *Create(){return new AudioPipe();}};As a possible optimisation I would like to change the deque to be fragments (const sized array of doubles) but not sure if that makes sense.
I am running with fragment size of 32 samples on Mac in release mode and in audio heaven.
A vsynth banana featuring 5 types of oscillator, an ADSR envelope and arpeggiator from unknown universe looks to be this weeks project.
Github does support SVN protocol.
Information here: https://help.github.com/articles/support-for-subversion-clients
Cool, am slowly getting the hang of structs.
Yup, got threading and debugger acting in most arbitrary manner. To be honest, it was nice to be back in unsafe environment:)
The actual call back needs to do a mem copy and increment a pointer so I will move that to a cpp file.
Or yes, it could block and wait for a monkey2 signal to say the copy has been performed on main thread…
Also, without a NoDebug flag like BlitzMax I think rule seems to be all monkey2 code should be app thread only no matter what.
I aim to implement a freeaudio style mixer in monkey2 code using float samples and just poll it per update to keep write pointer ahead of read pointer on some shared memory.
After machine generating (badly) the total API of 1630 lines here
https://github.com/nitrologic/m2/blob/master/modules/box2d/box2d.api.monkey2
I will probably cherry pick the bits needed for a minimal simulation, just not today.
Yes, I am using original C++ source.
I got sidetracked and wanted to find out how modules worked.
First Box2D test successful!
Monkey123456789101112131415161718#Import "<std>"#Import "<mojo>"#Import "<box2d>"Using std..Function Main()Print "monkey2 box2d test"Local down:=New box2d.b2Vec2(0,20)Local world:=New box2d.b2World(down)Local g:=world.GetGravity()Print "gravity="+g.x+","+g.yEnd -
AuthorPosts
