working Assembler memin workareound!!!

[trogluddite]

Here's an improved version of the shared ASM buffer using the Ruby Frame method - with a couple of basic read/write examples.

Shared mem.fsm

(126.82 KiB) Downloaded 1204 times

I've refactored the Ruby code to make it much more stable than before...
- Outputs zero address at startup by default during 'init' (i.e. before audio is started)
- Remembers previous buffer size, and restores on load during 'loadState' (i.e. before audio is started).
- When resizing, the old buffer is kept in scope until after the new one can take over - so there's never a time without a valid frame address.
- When making bigger, address is sent before size, so that the old buffer index is always in range even if the values arrive in the ASM on a different sample.
- Likewise, when making smaller, size is sent first, so that the new buffer index is always in range.

I've been able to load the schematic with the audio already running, and resize the buffer repeatedly on the fly - and so far, it has been completely reliable, but it needs some serious 'soak testing' in a bigger schematic to be totally confident.

[adamszabo]

Thats very nice! is it monophonic only at the moment?

[trogluddite]

Hi,
I made the demo mono just for convenience really, as a lot of testing is still needed. Other than the restriction that a float or integer are always four bytes wide, the Frame is just acting as a generic block of memory. To make stereo, mono4 or even arbitrary sized data structures is all down to how the indexes are calculated in the assembly.

However, I am thinking that for ease of use, I might make mono, stereo and mono4 'templates' where the essentials of the code are there in the form of code blocks that can easily be cut and pasted - maybe even as sub-routines that can be called using a label if the asm op-codes can support it.

If the Win32API bug that I reported yesterday gets a fix, or we can convert to a C++ .dll, this technique will hopefully become the medium for a set of "shared buffer" modules that will allow audio, MIDI or any other arbitrary data to be shared between multiple VST instances. Data could even be shared between multiple applications - though probably not audio, as clocking the data accurately is difficult when only one app' at a time can access the ASIO drivers.

I already have this working in a basic form, and it seems easily fast enough to stream audio in real time (especially if it were done as a C++ dll) - but the Win32API bug breaks everything when you export the schematic, which has put a stop to the experiments (only temporarily, I hope).

I'm working this weekend on turning my prototypes into something ready for posting, and will open this up to the community. We have a few good C++ coders about who might be able to make light work of turning it into an embedded .dll, or at least help me to get my head around it enough to get something working!

I don't see this as a replacement for KG's work though; that also has many merits - and I think the two will complement each other. His way of using the existing 'mem' data type has different strengths; the ability to take the data from wav. files and wavetables being a good example.

[Exo]

Thanks for this Trog great work!, I have converted it to poly and am now using it in my free running oscs Here

[KG_is_back]

Wow Trog.... you mem system works really good. It is ideal for tasks that involve sharing arrays/buffers between assembly components. However, it might be cool to debug my version too, because mine allows to extract pointer,size and stereo/mono mode from loaded waves (and wave arrays), which is much more useful for custom wave readers and wavetable oscillators.

[trogluddite]

Yes, they'll make a fine couple I think - always good to have a choice to suit the job at hand!

Do you have any examples of how the Analyser code changes sometimes? I'm thinking that if we can compare them, it might be possible to use Ruby Regex'es to parse the code - they're really good at picking out specific patterns when you don't know the exact position of what you're looking for. Fast too, as the Ruby Regex engine is a C++ library.
Not been able to get any good examples yet, though, as it all seems to work pretty reliably here so far!

[KG_is_back]

Yes, they'll make a fine couple I think - always good to have a choice to suit the job at hand!Do you have any examples of how the Analyser code changes sometimes? I'm thinking that if we can compare them, it might be possible to use Ruby Regex'es to parse the code - they're really good at picking out specific patterns when you don't know the exact position of what you're looking for. Fast too, as the Ruby Regex engine is a C++ library.Not been able to get any good examples yet, though, as it all seems to work pretty reliably here so far!

I believe that will not solve the issue, because when the bug happens, the code string from the analyzer doesn't get updated anymore (it doesn't even change when you disconnect the modules form the analyzer or change/remove the mem). anyway here's the example of the buggy code:

Code: Select all

***** Init *****
push ebp;
mov ebp,edi;
pop ebp
ret;
cmp eax,1998;  //this line is extra - it shouldn't be here. the actual code is random: sometimes it's ret; sometimes mov ebp,edi; sometimes completely different.
***** Sample Rate *****
push ebp;
mov ebp,edi;
push eax;
push ebx;
mov eax,119761008;
mov eax,[eax];
cmp eax,0;
jz 241
mov eax,127344016;
movaps xmm0,dword ptr[ebp+0]
minps xmm0,dword ptr[eax]
maxps xmm0,dword ptr [ebp+4256]
movaps dword ptr[ebp+4240],xmm0
fld dword ptr[ebp+4240]
fistp dword ptr[ebp+4224]
fld dword ptr[ebp+4244]
fistp dword ptr[ebp+4228]
fld dword ptr[ebp+4248]
fistp dword ptr[ebp+4232]
fld dword ptr[ebp+4252]
fistp dword ptr[ebp+4236]
mov eax,dword ptr[ebp+4224]
shl eax,3;
mov ebx,eax;
mov eax,119761008;
mov eax,[eax];
add eax,ebx;
fld dword ptr[eax]
fstp dword ptr[ebp+4192]
add eax,4
fld dword ptr[eax]
fstp dword ptr[ebp+4208]
mov eax,dword ptr[ebp+4228]
shl eax,3;
mov ebx,eax;
mov eax,119761008;
mov eax,[eax];
add eax,ebx;
fld dword ptr[eax]
fstp dword ptr[ebp+4196]
add eax,4
fld dword ptr[eax]
fstp dword ptr[ebp+4212]
mov eax,dword ptr[ebp+4232]
shl eax,3;
mov ebx,eax;
mov eax,119761008;
mov eax,[eax];
add eax,ebx;
fld dword ptr[eax]
fstp dword ptr[ebp+4200]
add eax,4
fld dword ptr[eax]
fstp dword ptr[ebp+4216]
mov eax,dword ptr[ebp+4236]
shl eax,3;
mov ebx,eax;
mov eax,119761008;
mov eax,[eax];
add eax,ebx;
fld dword ptr[eax]
fstp dword ptr[ebp+4204]
add eax,4
fld dword ptr[eax]
fstp dword ptr[ebp+4220]
pop ebx
pop eax
pop ebp
ret;


[trogluddite]

Aaah, I see. That's a real shame - guess there must be some sort of disassembly going on that is buggy.

[digitalwhitebyte]

Welcome back Trog.
Since I was the first to show you how you could do, and in the forum of SynthMaker I've always said that it was possible to do so, allow me to say a few things about it:

Having already built a DLL to manage memory for assembler, works well.

The system with the ruby unfortunately, suffers with the GC and some times change pointers.
With the system of KG, it still does not ensure, here the possibility of the change of the pointer allocated on the heap.

With the primitive hidden, even here it does not work well, it suffers from a bad conversion to integer.

So if you do not hurry
I will release a production version soon ready and tested well, but I do not think free ...
sorry but here in Italy we do business

[trogluddite]

Hi there DWB, nice to hear from you.

The system with the ruby unfortunately, suffers with the GC and some times change pointers.

Interesting. The GC I have seen no problems with, a matter of making sure the same Frame is always in scope and re-used so he never becomes garbage. Changed pointer? Hmm, not seen this, and would be strange to copy data in order to move the Frame. But, of course, it is possible - we do not know how Malc defines the 'Frame' class in his C-extension. So, yes, I share your concerns about such a hack, hence now taking the .dll route myself, although with a slightly different purpose in mind.

KG's method. I certainly share your concerns about this - obtaining data from dis-assembled code is an extreme measure for sure; and I think the text is really intended for Malc to de-bug rather than a user feature. Always interesting to look "under the hood" to see what hacks can be done though - just from curiosity if nothing else.

And of course, always listening intently to your comments - I learned long ago that your experience is ALWAYS valuable to hear!

So if you do not hurry

He he, time is no problem - but waiting is no fun, and every bug along the way is another opportunity to become a better programmer. But I am certain your solution will be good - I look forward to seeing it.