change pulse wave to digital pulse

cyto · 2 Feb 2012

in code...

streamin in; streamout dPulse; dPulse=((in>=0)&1)|((in<0)&-1);

...or even better (in asm)...

streamin in; streamout dPulse; int mask1=1606418432; int mask2=1065353216; stage0; movaps xmm0,mask1; pslld xmm0,1; movaps mask1New,xmm0; stage2; movaps xmm0,in; orps xmm0,mask2; andps xmm0,mask1New; movaps dPulse,xmm0;

-cyto

tester · 2 Feb 2012

Thanks!

I see you like coding 😉

From the perspective of SM (and then - exported files) performance - is there a difference between using regular codes or ASM codes in schematic?

tester · 2 Feb 2012

Hmm... I'm having the same problem with glitches here. Above is digital switch (the same on both - code and ASM), below - analog input. How can it be solved in code? In the same way like with glitches I had previously? Or maybe a matter of display this time?

martinvicanek · 2 Feb 2012

Hey tester,

strange, when I feed either cyto's code or ASM comparator with a band limited square wave, I get a "perfect" square wave out as expected. (I put quotes because the signal is not suited for audio due to heavy aliasing). So is it possible that you have some sort of filter or other processing between the comp output and the scope?

cyto · 2 Feb 2012

tester wrote: I see you like coding 😉

Yes, Ido 🙂

After thinking about this, here is an even better way... (for some reason I always instinctively go to integers to mask values, but you can achieve the same thing with floats and you save the "stage 0" shift)

streamin in; streamout dPulse; float one=1.0; float negOne=-1.0; movaps xmm0,in; orps xmm0,one; andps xmm0,negOne; movaps dPulse,xmm0;

And regarding the "glitches" you're experiencing: it must be your environment, because any of these code snippets will only produce 1s and -1s.

tester wrote: From the perspective of SM (and then - exported files) performance - is there a difference between using regular codes or ASM codes in schematic?

Obviously code is a lot easier to implement as you don't need to keep track of each individual operation that's going on. And a well written code will run quite efficiently. However, when the code gets "compiled," it often has redundant operations. SM has a tendency to only use the bare minimum of registers needed to execute, so you get a lot of movement in and out of memory for data that could easily be kept in the registers. I don't know if you have figured this out, but if you connect a "text" box to the "s" output of the code primitive, you can see how SM will "compile" the code into assembly.

For my own personal projects, I almost always program in assembly in SM. Even with the limited amount of opcodes available to us, it offers a lot more flexibility. I was initially daunted by those little green boxes and all the cryptic operations. But after deciding to dive in, it proved to be a lot easier than I imagined. It does require a certain mindset, but once you grasp a couple basic principles it's not too bad.

-cyto

tester · 2 Feb 2012

Thanks for explanation.

I'm rather a visual dataflow fellow right now; on my daily basis I work with audible sound itself, so I just follow what I hear, compare to what I know and adjust to what it should be. 😉

The glitches are probably due to way of displaying waves (cool edit) - maybe some auto-curvature between points.

infuzion · 3 Feb 2012

tester wrote: The glitches are probably due to way of displaying waves (cool edit) - maybe some auto-curvature between points.

Or due to "intersample peaks". Also be careful with Nyquest wrapping if used directly for audio & you don't bandlimit well.

tester · 3 Feb 2012

I'ts for slow modulators and switches - values less than 200Hz.