From the original SynthMaker forum (2004–2014), with its members’ names and dates.
infuzion ·
Seems that increasing the bit depth for floating point DSP seems to be more efficent than oversampling, and since SSE2 has been out for 6+ years (over 3 for AMD), could SM please have SSE2 processing? Might be easier to put it in phases (could be marketed that SM has "preliminary 64bit processing"):
1) SSE2 instructions opened for the ASM primitive (see below)
2) Introduce 64bit Stream connectors (just to connect ASM to ASM)
3) have 64bit Mono VST in/out
4) add converters to & from Poly/Pack4, Mono, & 64bit stereo
4a) rename Pack to Pack4, add Pack64Mono (merge 2 64bit Mono into a single 64bit stream)
4a) add converters to 64bit have noise generators for lower 32 bit (or connector in)
5) add primitives, starting with
+ Signal Analyser
+ Wave Reader (I assume wave tables can handle 64bit)
+ Wave Table Read
(edit2009: for some reason I had listed Envelope Control, Voices to 64bit, ASIO In/Out with 64bit... not really needed though)
++ somewhere here Code that can make 64bit ASM
+ Delay
+ ADSR
+ OSC primitives
+ everything else...
I hope phase 1 & perhaps 2 could added to SM quickly please. I understand the other phases would take a while... perhaps not until SM 1.5 or 2.0.
Here are the commands I hope to be added (edit2009: Why do I have Double-FP listed?)
addpd //Packed Double-FP Add
andnpd //Bit-Wise Logical And Not (for Double-FP)
andpd //Bit-Wise Logical And (for Double-FP)
cmppd //Packed Double-FP Compare compare
cvtdq2pd //Packed Signed INT32 to Packed Double-FP Conversion
cvtpd2pi //Packed Double-FP to Packed INT32 Conversion
cvtpd2ps //Packed Double-FP to Packed Single-FP Conversion
cvtpi2pd //Packed Signed INT32 to Packed Double-FP Conversion
cvtps2pd //Packed Single-FP to Packed Double-FP Conversion
divpd //Packed Double-FP Divide
maxpd //Packed Double-FP Maximum
minpd //Packed Double-FP Minimum
movapd //Move Aligned TwoPacked Double-FP movement
movhpd //Move High Packed Double-FP movement
movhlps //Move High Single-FP to Low {faster AMD vs Intel}
movhps //Move High Packed Single-FP
movlpd //Move Low Packed Double-FP movement
movlps //Move Low Packed Single-FP
mulpd //Packed Double-FP Multiply
orpd //Bit-Wise Logical OR for Double-FP Data
shufpd //Shuffle Double-FP
shufps //Shuffle Single-FP, requested before
sqrtpd //Packed Double-FP Square Root
subpd //Packed Double-FP Substract
unpckhpd //Unpack High Packed Double-FP Data shuffle
unpcklpd //Unpack Low Packed Double-FP Data shuffle
unpcklps //useful for merging 2 mono streams into 1
xorpd //Bit-wise Logical XOR for Double-FP Data
* rounding controlled by MXCSR register (bits 13 and 14)
ldmxcsr //Load MXCSR register
stmxcsr //Save MXCSR register state
(SM default of rounded off?)
Examples of how to get current 32bit streams translated back & forth to 64bit {this is latency for AMD,Intel}:
//Poly/Pack4 64bit process
streamin in;streamout out;
float temp32;
movaps xmm7,in;
cvtps2pd xmm0,xmm7; //{3,3-2} move positions 0&1 into 64bit float
// 64bit process with xmm0
cvtpd2ps xmm6,xmm0; //{10,11-10}
movlps temp32,xmm6; //{2,6-1} not needed if xmm6 isn't used in 64bit processing
movaps xmm7,in; //{2,6-1} not needed if xmm7 wasn't used
movhlps xmm7,xmm7; //{2,6} bounce positions 2&3 to 0&1
cvtps2pd xmm0,xmm7; //{3,3-2} move positions 0&1 into 64bit float
// 64bit process with xmm0, likely just copy the above
cvtpd2ps xmm7,xmm0; //{10,11-10} recycle xmm7
movlps xmm6,temp32; //{2,6-1} not needed if xmm6 isn't used in 64bit processing
movhps xmm6,xmm7; //{2,6-1} merge both stages
movaps out,xmm6;
// fini {total extra latentcy:37-30,57-32}
While translating 3-4 streams into 64bit will need twice as many instructions of DSP code as 32bit, if you merge 2 mono streams into one, you can use almost 1/2 as much instructions, since you don't need two seperate ASM routines:
//dual mono 64bit process
monoin iLeft;monoin iRight;
monoout oLeft; monoout oRight;
movlps xmm7,iRight; //{2,6-1} assuming Mono is posision 0
unpcklps xmm7,iLeft; //{5,4-2} position 0=right, 1=left
cvtps2pd xmm0,xmm7; //{3,3-2}
// 64bit process with xmm0
cvtpd2ps xmm7,xmm0; //{10,11-10}
movlps oRight,xmm7; //{2,4-1} hopefully posisition 1 is ignored by monoout
shufps xmm7,xmm7,2; //{4,6-2} move pos1 to 0
movlps oLeft,xmm7; //{2,4-1} hopefully posisition 1 is ignored by monoout
// fini {total extra latentcy (-4 movaps):20,20-12?}
sources:
[old link]
edit: almost forgot my connector suggestions (bottom 2 are SM's for ref):
I was trying to have cool colors, with 2 of something that looked wider than the Mono dot. I personally like the middle colors, with somewhere between the right & left lines.
edit2: forgot to suggest to have dithering down from double to single FP to have rounded off by default
cheers
rl ·
++vote
Also I'd like to have a double type for the high level code module, even when stream connectors only support floats.
infuzion ·
Thanks for the feedback rl; I was beginning to think people wer apathetic to my suggestion (not that is a bad thing... if noone else wants SSE2, then why should the devs waste their time?)
rl wrote: Also I'd like to have a double type for the high level code module, even when stream connectors only support floats.
So, you saying Code support should be priority 1.5 on my list? 64bit Code would be cool, but I hope more like 2.5 or 3.5... I hope to start chaining together 64bit ASM sooner since I'd hard to code things like delays & envelopes w/Hop8, which are harder if done in all in one block.
Besides, you can take the ASM output of the old single type Code, paste it into a text editor, find/replace the SSE commands w/SSE2, add my wrapper (if it works 😉 ), & copy/paste the results into the 64bit ASM. A bit of work, but not a big deal if you only convert Code when it's finished & releasable.
I wonder how that would work? Make variables declaired FloatD vs Float?
sambean ·
How about a code/asm SDK, help cut down on requests and such 😉
Sam
rl ·
So, you saying Code support should be priority 1.5 on my list?
no, your suggestions absolutely make sense. It's just that a double type is what I'm missing most e.g. this algorithm needs double precision, otherwise the filter is unstable.
On the other hand I haven't really started on ASM optimizations. I guess when starting, I will end up with similar suggestions to yours.
infuzion ·
rl wrote: On the other hand I haven't really started on ASM optimizations. I guess when starting, I will end up with similar suggestions to yours.
I'm somewhat comfortable w/ASM now, atleast the SSE math stuff.
infuzion ·
hmmm... I'd thought there would be more voters by now... I guess people who use SM don't have a computer? 😮
Thanks for those who have voted so far, & the feedbacks!
Tom7777 ·
I voted - Yes, I have atleast one SSE2 computer now
The reason i didn't say anything though is im not really a coder and this seems like a code related with all those code requests so maybe thats the reason theres not a load of post and votes. 🙂
Nu Audio Science ·
I voted cause all my puters are SSE2 but i didn't comment cause i'm crap at doing anything with SM unless you count booting it up and staring at it blankly 😇
infuzion ·
Thanks for everyone's honest replies & votes!
I'm suprised by the % of "not planning to buy" votes; this means over 10% of our readership are using computers over 3 years old? I suppose we have alot of poor students or something then...
For those who think a new computer might be too much; I've seen many dual-core desktops & laptops under $500USD here:
http://DealNews.com
& many stores are having fire sales to dump XP computers for Vista ones.
While I normally vote for the underdog (AMD), I'd have to say for the price, wattage, and heat efficency, seems that a Core 2 Duo will out perform a dual core when it comes to SSE/SSE2. I'd pick up a AMD x2 only when a comperable Core 2 Duo is out of $ reach, "Core Duo" (not 2) is fine, but avoid at all costs PentiumD: to hot & not worth it IMHO.
matti ·
infuzion wrote: hmmm... I'd thought there would be more voters by now...
I cast my vote to support the idea. 64 bit would be very usefull for people who use asm code modules.
I just recently updated from 600mhz P3 to 2x2.8ghz PD. I'd say it's worth it(cheapest core2duos cost twice more), unless you live somewhere where the normal temp inside a room is way over 40 degrees celsius. Single core amd setups might give more punch(per euro) if you run just one prog, but intel dualcores have that magical stability to them. Everything runs so smoooth..
infuzion ·
matti wrote: 64 bit would be very usefull for people who use asm code modules.
I just recently updated from 600mhz P3 to 2x2.8ghz PD. I'd say it's worth it(cheapest core2duos cost twice more), unless you live somewhere where the normal temp inside a room is way over 40 degrees celsius. Single core amd setups might give more punch(per euro) if you run just one prog, but intel dualcores have that magical stability to them. Everything runs so smoooth..
Well, sooner or later, I hope 64bit floats would happen thought all SM primitives, but it would just be the matter of adding a few commands to the ASM, no real programming AFAIK.
The PentiumD is a bargin chip for sure... but:
* To me, hotter = shorter lifespan & perhaps more instabiltiy (thinking I could take the computer in live locations, etc)
* Core2Duos are great overclockers, PentDs are simply too hot to try IMHO.
* I'm not sure but seems according to some latency charts, that SSE commands take fewer cycles on Core2 vs PentD... a verification would be great.
* I'm lazy, & only want to upgrade every 3-4 years, so spending a bit extra cash will keep me from upgrading early, thus saving time. But I only spend about $300 above cheap to do so, not $900.
matti, please don't think I'm saying you are wrong for grabbing your PD; I've gone the cheapest route before as well. I'm just letting others know some consideratons of mine, to equip them with a well educated choice. Actually, thinking about what you said, I'd suggest if you find a cheap cheap used PentiumD system (test it with a burn-in program & temp guage) in great condition, that could be the best bargin!
matti ·
infuzion wrote: The PentiumD is a bargin chip for sure... but:
* To me, hotter = shorter lifespan & perhaps more instabiltiy (thinking I could take the computer in live locations, etc)
Yeah, there's no right or wrong way to go. It's always a balance between features, disadvantages, power and price.
medanby ·
Having just built a nice new dual-core 64bit box of extravagance, it would be great to make use of all the instructions.
Perhaps the CODE module could have instuctions to enable creating assembly with or without MMX, SSE, SSE2, etc. Some more MATHS functions in CODE would be nice as well.
The CODE and ASSEMBLY modules make this product very attractive and quite distinct from others.
Looking forward to installing SM 1.0.2
Cheers,
Michael
infuzion ·
Well, if you don't have atleast SSE1, then you have a 7+ year old computer, & most like not able to afford SM, nor any commertial VSTs made by it. It would be neat to have the Code to switch from 32bit SSE to 64bit SSE2 by an input... I guess we'll need a CPU primitive that told us if the host computer has SSE2 abilities or not. (But it may be a moot point if it takes a few years for SSE2 to get added to SM, & the SSE1-only computers will also be 7+ years old at that point. I'm indifferent, just don't want the dev team working TOO hard)
Exactly what math functions in Code do you want Michael?
medanby ·
Funnily enough, infuzion, my last PC was about 7 years old!!!!!!! Until the new PC I could only dream about a CODE and ASSEMBLER module. It was a hard time !
I had been using a freely available maths packacge (Scilab) for non realtime audio DSP and found uses for a lot of functions.
First of all sin1,cos1 and tan1 could have their inverses.
Second log10 could be accompanied by loge and exp.
Third a bit of power is good ^ and follows on from 2, sqrt can be done with ^ but always looks nicer as sqrt(x)
These of course can be coded from a little knowledge of Maclaurin & Taylor expansions, but is, however rather long winded. I guess that really means if you like beans the inevitible will happen more frequently whilst coding. Thinking of M & T reminds me of;
Fourth Factorial n! ie 1*2*3*...n
1,2,3 would be a great starting place I find the CODE module far friendlier than all other 'high-level' IDES which change syntax so often with version that, unless you use them all the while, you're forever reading the help files which is CR|) (censored for US friends).
I intend to write some Spectral processing software which I have made some algorythms for obviously that brings me to the next request;
Fifth FFT & IFFT Real to complex & complex to real The HOLY GRAIL V
Of course I have posted elsewhere for the inclusion of an IFFT to accompany the GraphFFT component.
The CODE component with these would be like mana from heave? (not to offend any atheists)
What does everybody thing?
Michael
infuzion ·
I know you guys have alot on your plate, but I hope this is in the burner somewhere... Now that is is easy to find a SSE2 computer for less than $400USD new, $70 used, there shouldn't be much of an issue of compatibility, unless maybe one is making free VSTs for broke people. Also, 64bit audio (not talking OS here) is becoming standard, like in Live7, so it is becoming expected (at least with the clients I'm trying to attract). New computers can handle SSE3, & newest some sort of SSE4...
So please add SSE2 & maybe 3 ASM soon; shouldn't be too hard.
A primitive that output what level & kind of SSE the CPU can handle (or that outputs the raw CPU ID & the module would sort that out). Not a big deal though, I don't mind releasing an extra SSE2+ only version & people can use CPU-Z
cheers
TomC ·
Oh, I missed that posting.
Bumpidy bumpidiy bump
Cheers.
Tom
infuzion ·
...pretty please? Even if only in the Assembler? Live & many DAWs have 64bit audio, & many of the new SSEx instructions can help make even faster code.
BTW, the SSSE3 & SSE4 instructions look nice, even if they are Intel-only.
infuzion ·
A few more "votes" fore a fuller 64bit support:
1 sample delay for double stream?
Truncation math
infuzion ·
Did I forget to mention that SSE3 speeds up FFT?
http://www.fftw.org/
http://ieeexplore.ieee.org/xpl/freeabs_ ... mber=34759
http://developer.amd.com/documentation/ ... 07122.aspx
http://www.springerlink.com/content/6481607675376w42/
aliasant ·
Could it be so that that the developers is saving this for SM 2.0 ?
That is if SM 2.0 isnt just a fairy tale...
infuzion ·
aliasant wrote: Could it be so that that the developers is saving this for SM 2.0 ?
Since the time of the original posting, we did get some Stream "Double" math primitives (really just for the sample playback modules), so that is a step in the right direction. But of course, we/I want more!! 😈
Really, I'd be happy with just all of the ASM commands open in the ASM-code, or atleast SSE2-4.1.
kirkagur ·
aliasant wrote: Could it be so that that the developers is saving this for SM 2.0 ?
That is if SM 2.0 isnt just a fairy tale...
+1 For the 64 Bit before SM 2.0
TheAudiophileDutchman ·
About timing: Wouldnt it be great to have an SM v2.0 beta as soon as we hit 2000 total members @this SM forum? (currently #1932) 😇
infuzion ·
TheAudiophileDutchman wrote: About timing: Wouldn't it be great to have an SM v2.0 beta as soon as we hit 2000 total members @this SM forum? (currently #1932)
That's about when a 1.1.3 beta will be out, & SSE2+ is not in there. 🙁
Nice to see an old face back here Mr Audiophile Dutchman !
TheAudiophileDutchman ·
infuzion wrote: Nice to see an old face back here Mr Audiophile Dutchman !
Thanks, infuzion. I hope to share some 'fireworks' again in 2009! 😀
RuleT ·
It seems I don't have permission to vote, but verbally I vote for the first option "Yes, I have atleast one SSE2 computer now". And I completely agree with infuzion's offer! 😉 And even more, I offer to add SSEX (X is version), MMX & 3DNow!(maybe useful), etc.. and expand current SSE1 & previous x86 opcodes list. 😈
Of course, it brings many difficulties, and I think that any improvements should not decrease current simplicity and reliability. Therefore, it may take much efforts.
infuzion ·
RuleT wrote: It seems I don't have permission to vote...
I made it limited time. Pointless to re-open it now, since one can buy a brand new SSE3 compatible netbook for
50.
Honestly, I've given up on the idea of SM having SSE2+ this decade. When I get to the point of needing it bad enough, I'll just learn C++ & port.
infuzion ·
infuzion wrote: ...since one can buy a brand new SSE3 compatible netbook for 50.
If one really looks hard enough, [urlhttp://dealnews.com/categories/Computer/PC-Computers/PC-Laptop/Netbooks/535.html]netbook sales are 00USD[/url] now, so SSE2+ is for the masses. I've been poking around SM's internal ASM, & see that there are many opcodes not available for the ASM primitive... please share some Christmas love here & let us have SSE2 & 3.
😉 😇
aliasant ·
Christmas loving would be very nice indeed.
lets mailbomb Malc to "convince" him of updating the ASM SSE part.
These are the instructions sets my new i7 has and I assume most other new CPUs has the same.
x86, x86-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2
What of these do we have in SM?
I guess: x86, SSE, SSE2 and only parts of it too or ?
infuzion ·
aliasant wrote: lets mailbomb Malc to "convince" him of updating the ASM SSE part.
These are the instructions sets my new i7 has and I assume most other new CPUs has the same.
x86, x86-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2
What of these do we have in SM? I guess: x86, SSE, SSE2 and only parts of it too or ?
I mailbombing is a good idea. I do think that people who released effects for mastering (bootsy, perhaps McBarGig) can make a case that bigger floats will make their effects sound more professional. That's how Ableton Live addressed the issues with Live5 sounding too "digital" for final mixdowns as a DAW; adding 64bit floats to effects. Also if someone needs supper fast FFT SSE3 is the way to go.
SSE3 is well covered by all x86 CPUs released over the past 5 years. SSSE, & everything above that tend to be vendor specific.
There is only a small subset of x86 & SSE1 available to users ASM. There are a few more opcodes currently used by SM's other primitives not available to us directly in the ASM primitive. Only 2 SSE2 opcodes are directly available us are to help with converting 32bit floating point with 32bit integers.
I'm sure when SM was created 8 years ago SSE1 is fine, & is OK (though may be faster in a few cases) for just instruments, but when it comes to effects, many other VSTs use 64bit+ floats, so they naturally sound better.
aliasant ·
So what would it take for Malc to make this real ?
We all know he is very busy working on a ton of things so if this is hard to incorporate into SM....
Would it be easy for him to add this to SM?
Isnt this just instructions that needs to be added to a list or does it require a total rewrite?
infuzion ·
aliasant wrote: So what would it take for Malc to make this real ?
Adding the opcodes in the ASM only? Three (3) hours.
Adding new connectors: a day? The only primitive I'm really worried about is Double Poly to Double Mono since most everything else can be made in ASM I think, so maybe a few days/week coding & testing I'm guessing. Adding float double primitives for others (Like wave/wavetable readers & players) 1 to 60 days I'm guessing, depending how much malc wants to implement. Almost as many man-hours as this thread took. 😉
infuzion ·
From my research, it seems that Christian Budde & others believe that switching from 32bit to 64bit floats help stabilize filters
Andrew J ·
infuzion wrote: From my research, it seems that Christian Budde & others believe that switching from 32bit to 64bit floats help stabilize filters
Yes the increased precision helps with stability. However there are techniques for implementing filters as a series of second order filters in 32 bit which can also achieve good stability.
MegaHurtz ·
sse3 does this "addps,xmm1,xmm2,xmm3;"
+1!
infuzion ·
MegaHurtz wrote: sse3 does this "addps,xmm1,xmm2,xmm3;"
+1!
Thanks for the vote, but you are mistaken of what sse3 does.
MegaHurtz ·
Yr right my friend, had a less hungover read and came to the same conclusion.
It`s the moving within registers that`s elaborated... Still +1.. +1...+1.
infuzion ·
MegaHurtz wrote: sse3 does this "addps,xmm1,xmm2,xmm3;"
However, in a not too distant future, there will be a fused multiply add coming to your desktop CPU. So if in your example xmm1 = xmm2, then you will be correct
then.
TheAudiophileDutchman ·
Votes= Votes + 1 (maybe cheating, as in the past I must have voted for this before) 😉
Full SSE2-support would at least also give SSE-integers and almost 100% compatibility with PC's of current users... andin case of full SSE3-support this may also be >90%...
infuzion ·
TheAudiophileDutchman wrote: Full SSE2-support would at least also give SSE-integers and almost 100% compatibility with PC's of current users... andin case of full SSE3-support this may also be >90%...
I'm sure very very few will not have SSE3, since even netbooks have SSE3... unless you have a netbook with an ARM CPU 😉 . I personally don't care about that tiny % without SSE3, since I want to sell VSTs.
infuzion ·
6monthfrontpagebumpplease
Jay ·
+ vote
Whilst i don't understand ASM nor use it, i do think you guys should get 64bit support.
with computers being dirt cheap nowadays, I truly do not know of anyone using a machine (for music creation) any less than dual core!
(If you are then i am sorry for you 😉 )
dual core and 64bit computing are now seen as a basic setup afaik, even most of the low budget computers from many of the manufacturers out there fit this standard
If you don't have multicore and 64bit computing then time for a new PC 🙂
infuzion ·
Jay wrote: with computers being dirt cheap nowadays, I truly do not know of anyone using a machine (for music creation) any less than dual core! If you don't have multicore and 64bit computing then time for a new PC 🙂
Even the Atom chips used in Netbooks have SSE3.
infuzion ·
4+ years... 😝
aliasant ·
infuzion wrote: 4+ years... 😝
Dont be in such a rush.
Give it another 4 years and if theres still nothing you can always post another 4+4 years or something 🙂
tor ·
quad bump
trogluddite ·
He he, I wonder what machines those 5 'No' voters are using now?! 😉
tor ·
lol
any hows... i guess the option to compile non sse2/3 shuold be there as non sse is now.
As Winnie-the-Pooh said so many times: Yes thank you.. both please 😉
Wrote something here? To have a post removed or your name hidden, write to [email protected].
SynthMaker