Some Looping Code - and some questions.

flamingRedDingo · 17 Oct 2010

Sorry to reply to my own post, but I've seen 12 or so downloads, so clearly somebody has been looking at my mess 🙂

I may have figured some things out - but I'd like some verification of my assumptions before I proceed 🙂 anyone, interested - it would be greatly helpful...

I did some cursory analysis within my host (FL Studio), and it does *roughly* appear as though my buffer is taking 4 TIMES the space I would have expected. Is this true?.. I expect about 180megs or so but it's using more than 600!

If the above is true, then I think I understand the 4x SSE thing. Basically, I'd want to pack the L/R channels of 2 loops into each mono4 (or poly?) and apply the outputs as though they were all in the same buffer location... Unfortunately this means that my loops must be paired (each of the pairs would have to be the same length, since I am subdividing the large buffer) ... but they'd also have to share the record/clear/mute flags and volume levels - that's not acceptable, at least for the requirements I need...

BUT, I *might* be able to run a cursor over a buffer and input, + output, 4 INDIVIDUAL channels, so long as the loops were paired with respect to length... IF this is true, I can work this way - I just need more code segments (or widgits) rather than containing all of the logic in a monolithic code segment like I do now:

So my main code window would expose the ins and outs as seperate streamin/streamout quads over the SAME buffer... so long as the lengths of buffer 1 vs. buffer 8 and buffer 3 vs. buffer 10) were the same I could do all of my muting and leveling on the individual streams... anyone know if I am on the right track here?

trogluddite · 18 Oct 2010

Welcome to the forum.

I've been working on a long-running project involving taking loops from audio, so I have some insight the problems you are trying to solve. You can find the schematic HERE, though it is probably a little convoluted to really help you much.

Your assumption about the buffers is spot on - each buffer location (or code variable etc.) contains four 32bit float values, hence 4* the expected buffer size. That's true even if you use the mono data type, because it is inherent in the way that sse assembly code works.

The way that packed mono4/poly works is kind of tricky to explain, but I'll give it a whirl. The four channels always execute exactly the same instructions in the same order, but any values written/read to memory and the registers always contain four channels, which always remain independent of each other. Using the pack and unpack primitives, it's possible to access each channel independently outside of the code, which hopefully this little diagram will illustrate...

The important thing to notice is that the parameters for each channel can be completely independent - as long as the buffer is as long as your longest loop, there's no reason that your pairs of loop have to have the same lengths, flags, or anything else. Only if you feed a mono4 input directly from a 'green' link (without the pack) will they all see the same value.

You'll see that I used streamin/streamout rather than poly. This type of in and out will take on whatever data type gets connected to the module's outputs - handy because there is no 'mono4' type to declare in the code like there is for poly. The reason for that is that the poly data type is a special case - it only works with the MIDI to Poly primitive that handles assigning synth voices to different sse channels - so without a MIDI signal to drive it, poly code won't run.

The trouble is that the mono4 and poly are not compatible with each other - using the packing/unpacking to give loops independent parameter values will only work using mono4, which has to be running constantly, so you don't get dynamic polyphony. OTOH if you use poly so that only loops being used consume CPU, you can't target your parameters at any particular voice.

Hence, in my own design I've used mono4, so that the loops are truly independent.

The bitwise logic actually works in a way that is very desirable most of the time - for doing conditional operatiions like the index=index&(index<length); that you have in your code. That's far and away the most common use for bitwise operations in SM code, simply masking either all or none of the bits in a float. This hints at why your integer boolean isn't working - converting to integer would foul up an awful lot of code, because conditional statements are just as useful in float as they are in integer, if values were converted to integer there would be no way to do, for example x = x + (SmallChange == YesPlease) & 0.01; - which is essential for many operations on an audio stream. In fact, there is no integer data type at all in SMs code - becuase the sse assembly that it compiles into only supports very limited integer operations. In assembly it is possible to declare 'int variable=n' to have an integer variable - inputs and outputs will still always be floats, but you can convert them to integers using the cvtps2dq opcode, and back to float with cvtdq2ps. But it's important to remember that all maths operations (addps, mulps etc.) always assume that you are using floats, so they will give very odd results if fed with integers without explicitly converting first.

flamingRedDingo · 18 Oct 2010

Thank you so much for your in-depth response and your code! 🙂 I may get the hang of this stuff yet. Everything you have told me makes sense. And the idea about using a streamin to tie 2 different lengths together - aha! thanks man.

Also I think a facepalm is in order regarding the bitwise ops: I swear I tried this the other day and it didn't work:

monoin in; monoout out; // get the 3rd bit out = in & 8; I wired this up to an Int element input, and a mono to float sampler for output and I wasn't getting the result for the 3rd to 16th bits... maybe I didn't have enough caffeine in me before - but in the end it seems I was mistaken in the initial post. IN. let's see if it holds up when I actually go to apply it.

Cheers mate, I'll credit you in my final - even though it seems you've already built your own...

trogluddite · 19 Oct 2010

flamingRedDingo wrote: I think a facepalm is in order regarding the bitwise ops

Don't beat yourself up just yet! You are correct in saying that your code doesn't get you the value of the third bit - even if you feed the code with a 'Green' integer, the numbers will still be floats inside the code. And the bitwise representation of 8 as a float is not 1000. I got lost myself trying to understand this when I started using SM code, so I ended up making a couple of modules for converting from float to bitwise and back again - you can find them in the Developers Toolkit (well worth a download, many people have contributed to the modules in there - good to learn from as well as to find problem solving gadgets)

The screenshot shows how 8 is represented as a float - and bit 3 is a big fat zero. Also shown is what 1000 bitwise comes out like as a float - 'Denormal' (Aaargh!). And as you can see, even something simple like 65535 & 1 gives some weird results when bitwise Anded.

The IEEE754 is a reference to the industry standard way of representing floats in most computers - Wikipedia etc. have some good links for info on that. But it's not really important to understand all the maths - just to remember that bitwise boolean is operating on a very cryptically encoded version of your numbers (unless you want to delve into assembly). Apart from the very special case of true/false comparisons (Anding with all ones or all zeros), the result is very rarely useful. That's not to say that you can't use flags - but it's generally simpler to set aside a whole variable for each flag than to try and share the individual bits of one variable (memory is plentiful, and there is no real CPU efficiency to be had from sharing a variable). The sse mono4 stuff probably does away with the bitwise stuff anyway - and that will do wonders for your CPU usage; those modulo functions will be what is sucking up a big chunk of your CPU.

flamingRedDingo · 19 Oct 2010

On using the flags: It's not so much about sharing a variable per se, but sharing the *input* (I don't want tons of input connectors for each individual loop if I can help it)

Also, I've produced a ground up recreation of the looping code, which while still unfinished, is far more polished and efficient than the original. Plus it's got a lot more documentation. Keep in mind the reverse setting is not implemented yet even though there is an input for it (it does nothing at the moment)..

I still haven't thrown timing correction for non-integral lengths yet, and also there is no clipping and no interpolation yet..But I did add the implementation for the 4th loop (it was impossible not to, actually, due to the way my loops are paired)... I also added a bunch of functions for the loops including leveling and offsetting. ALL this extra stuff is now running, and I'm using half the cpu and a quarter of the memory I was before. Thanks trogluddite!

I was wrestling with the idea of allowing the loops to play at speeds other than 1:1..in the end I don't think I am going to do it because I would have to retool my code segment to feed the individual streams to another set of code segments (selected w/ a selector) or I'd have to essentially apply resampling to each individual buffer regardless of settings (due to lack of true conditionals in SSE) I might be able to get away with conditionals in asm? but it doesn't seem worth it to me...

flamingRedDingo · 19 Oct 2010

Regarding the bitwise/float thing... I do understand the IEEE float standards, and this is what my original post was complaining about. As you said, the bitwise layout is very cryptic, and so what I was originally saying was that bitwise ops don't generally make any sense when applied to a float memory representation. Now that I have a firmer handle on SM w/ SSE and how the code segs work, it seems more a limitation of SSE per se, but it's still extremely annoying. I'd like to see a prominent disclaimer in the SM manual, but then again, I'd like to see A LOT of things in the SM manual =P

Cheers

trogluddite · 19 Oct 2010

Thanks for the feedback - it's always hard to know where to pitch posts when you don't know how much knowledge a new user already has (not forgetting, of course, that a bit of over-explanation can help other readers of the thread.)

flamingRedDingo wrote: I'd like to see A LOT of things in the SM manual =P

Yeeeess, 'Getting started leaflet' would probably be a better description - though in a twisted way, it has a good side too - it encourages a kind of communal 'self-help group' kind of atmosphere here on the forum coz we're all in the same boat together - far fewer of the dismissive "RTFM, noob!" kind of posts that I've seen in other user forums.

Something for you to bear in mind as you push on with your design - the assembly part of SM does open up some good optimisation options (including integers) - BUT SMs assembler also has a fair few limitations. If you search the Wiki for 'opcodes' you will see that only a select subset of the x86 and sse opcodes are recognised - it's very concentrated on the original sse extension; great for number crunching, but lousy for program structure. Conditionals particularly don't get much easier due to the lack of support for many non-sse opcodes - doing anything useful that involves isolating an individual sse channel is tricky - especially for poly where you are not in control of how the channels are assigned. I find it a weird reverse of the 'proper' way of programming I learned years back - instead of thinking in terms of what to execute when a condition is met, you have to think in terms of sse running every line whether you like it or not, and masking out the changes you didn't want!

BTW - lovely readable code and schematic - so many 'can you have a look at this for me' posts come complete with a cubist spider's web style schematic!

flamingRedDingo · 19 Oct 2010

I'm glad my code is readable (to at least some folks)... I was trying to as much as possible, keep all of the hairy bits inside the code window, because despite weird conventions, it's still a lot clearer to read something like "index = (index + 1) % length" vs. having a schematic that does the same thing...

Since I've been coding since 1986 =) I've had plenty of exposure to building logic without conditionals - so that doesn't really freak me out, even if it does get a bit unwieldy and error prone... Overall, I see myself heavily tending towards designs that rely mostly on logic in a code window vs. schematics... I just wish I could rely on it more for UI stuff as well =P but it's not suited for that.

I'd still like to know a bit more on Poly channels - you said they were essentially a special case basically for midi voices, but it seems they have other uses based on the number and variety of poly connectable components I am seeing in the toolbox...

I like SM's code thing, but here's a rant about it's most annoying shortcomings, just to get it off of my chest:

Not being able to declare buffers of a non-static size STINKS. At the very least, I should be able to at least connect a Mem Create output with the code window and access it as though it were a buffer, but seriously, I should be able to do something like this: buffer = new float[x];

not being able to do this (even in stage 0) is just too much of a limitation for many applications... at the very least, even a simple delay should be able to be allocated based on host samplerate, etc.. this would require arrays of a non-static size...If anyone knows any way to accomplish this more or less INSIDE code (or at least w/ an efficient way to access the dynamic buffer INSIDE the code) it would be very helpful.

Also, it seems strange to me that there is the rndint (or is it intrnd) function but if you want to take a an int as a truncated float (not rounded) you need to do something like so: x = x - (x%1); shouldn't there be a straight int() function?

It seems kind of bad to not have pack/unpack statements available in SM code. The absence of such operations at the code level imposes a huge burden of additional complexity when needing to perform some operations that require analysis or manipulation of the single streams inside of a mono4... if you can do this in asm, it seems reasonable that supporting pack and unpack in code wouldn't be that difficult. I'm sure I'm not the only person who has run into this issue.

It seems counter-intuitive to me that the code window limits multiple operations to 8 in one statement. running out of registers shouldn't happen. The register usage can be tracked with the AST tree you get by parsing the code. Since *at least* a partial Abstract Syntax Tree is generated, it is not a complex task to automatically break out long expressions into smaller statement w/ an assignment and local already included - the AST practically does it for you. Your C compiler will do this even - (if you consider the the register usage in the final executing CPU code)...It's not hard to do. Every other language package out there does it (at some level or another) Why doesn't SM? It smells like cutting corners, to me.

I really hope that the SM developers put some focus on shoring up some of these issues in the code window...

trogluddite · 19 Oct 2010

Yup sure can be a pain sometimes! (Though not as much as my old ZX Spectrum - I'm of the Sinclair/Commodore generation too) If you do some hunting you'll find many posts along the lines of 'I love SM, but had enough now, I'm downloading the VST SDK and learning C++'

I think this is really a conceptual thing - the designers of SM wanted to create a package to enable inexperienced programmers to create their own VSTs without all the hassle of 'real' programming. The code and assembly support are really a 'programming lite' supplement to enable people to create their own custom modules without the hassle of an SDK (the customisation route used by some rival products like SynthEdit) Same thing with the way poly is tied in with MIDI voice 'spawning' - us folks that want to make loopers/MIDI FX/convolution engines etc. are on the fringes of what the software was really intended for - it is called SYNTH_Maker after all. I'm one of those lucky people that gets a buzz out of bodging DIY solutions from whatever rubbish I have to hand, but SM has certainly been frustrating for many people who have a clear goal and a perfectly worked out algorithm, only to find that SM doesn't give them the means to achieve it.

None of this is helped by the fact that SM is essentially a one-man product - the developer, Malc, seems a lovely helpful guy - but SM seems to have gotten bigger than he has the time to handle; updates have been painfully slow for a long time now, and have mostly been fixes to VST host issues rather than enhancements to the features - and now he has the new FlowStione software to deal with as well.

Dynamic buffers, aah, I too would love that. Just to tantalise us, you can actually type in 'memin MyBuffer' and see the syntax highlighted in all it's glory, and then connect the code to a dynamic 'Mem Create' primitive, only to find that it hasn't been implemented! 😠

Packing/Unpacking can be done in assembly to a limited extent, as you can push/pop individual channels to the floating point unit's stack (e.g. fld MyVar[0]) and the shufps opcode can swap the channel order.

The poly thing is very much synth/sampler orientated. The only way AFAIK to initiate a poly 'voice' is with the MIDI to Poly - each active voice then occupies one sse channel of the schematic, and a new 'copy' of the code is started when you reach voice 5,9 etc. as each block of four sse channels gets filled. The shutting down of voices is handled by a hidden mechanism that accounts for the release of envelopes as well as the note off commands. You can spawn voices from MIDI messages created within the schematic, but apart from maybe sampling a value with the note trigger, you can't target parameter changes at any specific voice - typical behaviour for the GUI controls on a VST instrument, but not too useful for much else. I would have loved to be able to dynamically allocate resources in a poly style for my looper, the scalability would have opened up a load of possibilites (and CPU savings when I'm not using the full complement of loops)

Anyway, hope you don't get too put off - always nice to come across someone with similar ideas (i.e. not trying to make yet another Trance Synth clone). but like anything, you gotta find the tool that suits the job, and suits you. (or just become a masochist like me - I used to love going down Yorkshire caves/potholes in the middle of winter, maybe that's why I like SM so much!)

flamingRedDingo · 20 Oct 2010

It sure sounds like we have a lot in common WRT to creating stuff out of rubbish =)

I wrote my first digital recorder app on Apple ][E.. 64k of buffer and used the cassette jack to get the sound =P

I'll keep the memin thing in mind. Maybe Malc will get around to it one day...

In my opinion (and I'll probably get jeers for this), something that is purely a synth designer is basically useless nowadays. The reason is that we simply have so many offerings out there for additive, FM, subtractive, hybrids, and every other sort of synth out there. I am nearly positive that I can achieve any Synth sound you can produce with synthmaker with one or more synth products that are already available....

Seems to me like SM's biggest assets are: 1. a MIDI controller builder - I can build a UI that links my controller(s) to my host in a way that fits my intended workflow.

2. an effect builder (including LOOPING!). Unlike synths, there's a lot of uncovered territory WRT to VST effects...

If I were Malc, I'd consider the name "Synthmaker" to be something of a misnomer, and follow up with that by focusing on improving the areas where synthmaker can allow people to bring something new and creative to the table - in terms of effects and MIDI/host control. Building synths just doesn't make the cut, IMO

Thank you again for all of your help. Despite synthmaker's limitations, I think I can finish it with what I've got. In that spirit, I'll continue to post pre-release revisions of my looper on this thread. Once it is developed enough for general use I'll post it in the examples.

flamingRedDingo · 20 Oct 2010

In retrospect, I should have mentioned that I am one of those contrary bastards that likes to use things for purposes which they are not intended. An example: While I have paid for FL Studio (and I love it), I am not using FL the way it was designed to be used either... I set it up purely for live, so File|Save is useless for me... since File|Save is essentially what separates the Demo from the Full Version, turns out I never really needed to pay for it...(I could have saved my project on a friends machine, and loaded it on mine)... I suppose if my project ever gets out, the good folks at imageline will blacklist me, since I have essentially made registration of FL Studio useless (at least when used w/ my project)

So yes, I am one of "those" people =). I suspect you are too. I've really enjoyed reading your posts. They are incredibly helpful, and damn but if I don't like the way you think =)

Cheers

trogluddite · 20 Oct 2010

😊 Don't get compilments like that very often, cheers.

interesting point about your FL (mis)use. When I first showed my looper around, the immediate reaction of some people was 'It'll be great once I can load loops from my sample CDs, and save mangled loops to disk' - hence the laboured explanation on the download post and user guide to try and get across that it will never have those features, it's not meant to have them, they would ruin the principle of it, that isn't what it's for!

After a few years playing in DIY punk bands, I thought it'd be cool to have my own studio - and then rapidly realised that multitracking a la Mike Oldfield (albeit a bit noisier!) bored me to tears - and I never ever finished anything. I want the visceral experience of making music in the here and now, and the buzz of not being able to re-visit, re-time, re-tune - if I cock-up, I gotta just make it sound like I did it on purpose!

Sounds like I use Cubase simlarly to how you use FL - I just need a host that lets me route things flexibly (SMs exes are always mono in-stereo out, yet another bugbear) and maybe record the final output for the 'archives.' I use SM in the sense of my old DIY punk days of hacking together my own guitar pedals - making my own plugins lets me bend my sound the way I like without the diktats of a developer somewhere who's promising me that their plugin will help me to sound like the crap I hear on the radio (or did I mean karaoake bars, it's hard to tell the difference).

That's not to say that I think my music is world-shatteringly good or mould-breaking, just that I feel like it really belongs to me.

Keep up the good work - and rest assured there are other similarly motivated people here in SM land (they just get out of the house more than I do!)

flamingRedDingo · 20 Oct 2010

Heh...

I spent years running my own studio .. I was never particularly "pro", but I'm an audio nerd with a good ear, a love for making music, and a lot of pricey gear...That was until my studio was burglarized - but I'm over it now mostly.. still stings a bit... The point is that I spent years doing what you described, and I eventually came to the same basic conclusion as you - your desire to play "here and now", rather than go over and retune, remaster, resequence... etc

So nowadays, I'm really in to Bob Fripp style looping, - throw in a MIDI keyboard/controller, a ton of sample banks and some wierd VST gadgetry and you'd have my setup... It's great for live stuff, and because I can trigger pre-sequenced piano-roll patterns (midi like sequences) with keys on my kbd I can have the best of my sequenced stuff available for live perf...And of course I can still just "free play" too =)

I'm a big fan of Reggie Watts ... he uses a DL-Line6 delay pedal and a microphone. That's it. And he rocks the house.. youtube has a bunch of his stuff up. I highly recommend a listen. The reason I bring him up, is that he has basically inspired my latest setup.... add a kbd/sampler into his setup, and you'd have my setup =P As simple as it is, I like doing more with less... Screw the fancy 24band EQ's, the fancy maximizers, and the fancy editing.... I'm done with making my tracks in a studio... Nowadays, everything is live for me. Even in the studio =P

trogluddite · 21 Oct 2010

Wow, can't believe I never heard Reggie before - what a talent; not just the music but the attitude and comedy too - thanks so much for the pointer 🙂 Weird, I have had a mic up for testing throughout making my looper, so pretty much that's all I've used with it so far - but the intention was always to plug in guitar, drums, keys etc. - kind of a 21st century one man band. But those vids really make me think twice - maybe I haven't simplified enough yet! (apart from the extra mangling effects on the looper - need those to make up for not having anything like that level of vocal and lyrical virtuosity!) I'll see about going through some of my test recordings and posting up an example or two (problem is, I'm still at the stage of learning how to 'play' the technology, so every recording is an hour long with maybe 30secs of listenable bits - and I hate stereo editing!)

Bummer about your studio - but at least it seems you have found the silver lining to the black cloud. Do you have any of your sounds posted up anywhere, I'd really like to hear what you're up to. I've been such a plugin programming geek these last couple of years, I need some inspiring to get off my ass and actually make some damn music again!

flamingRedDingo · 22 Oct 2010

Looks like I broke the forum trying to upload an mp3 =/ I'll have to go set up some free hosting space to post my work... until then, I'll stick a pin in it...

I'm pretty much in the same boat you are WRT to the stuff I've produced with my looper setup... This is mainly due to the fact that I haven't found any loopers that do a couple of things I really need - stuff like picking up the last X bars of what I just played and start looping them... and also I have had issues getting my rehearseOut2Headphones/copyLoopToOutput mechanisms to work using host automation and 3rd pary loopers (like AngstromLooper or Elotronixx)... That's why I've started rolling my own looper...

Speaking of which - I built most of a UI and plugged in my looper code to it, but in doing so, I've come to the realization that in fact, the fixed memory allocation issue is too much of a problem... It's creating far too many issues and destroying usability...

What I'd like to do is use Mem Create, Wave Read, Wave Write instead, if it's feasible.. So far, my attempts to use these critters have yielded nothing but FAIL... Google searches aren't bearing fruit either...

Since you seem to know what you are doing, I was wondering if you knew how these work... If I could just find a simple component that does precisely what the "Delay" component does, implemented using Mem Create, et al, I'd be set...

The other thing I'm worried about is performance ... *If* I can wire up such an animal, is it reasonable to expect that I can get near the same level of performance that I do in my current implementation? or is running 4 stereo (8 mono) loops going to eat my CPU?

flamingRedDingo · 22 Oct 2010

In the interest of clarifying what I was trying to do in my last post, I've attached a copy of a remedial schematic that illustrates what I am attempting...If I can get the example to work, I'll be golden, and attempt to revise my looping code...

I've also posted another evolution of the loops schematic... this one is 4x stereo looping at 48000Hz ... but it has the beginnings of a UI too... which I should add, has several goodies I've developed (presettable vector push buttons, presettable vector toggle buttons/switch, some conversion modules, etc...)

PS: As I said, I'll post some MP3s after I set up some sort of free hosting (though I don't have anything polished that uses my looper setup yet)... the forums don't like it when I try to post MP3's ...

flamingRedDingo · 22 Oct 2010

Looks like I answered my own question...

Here's a very raw arbitrary size looper using Wave Read/Wave Write and Mem Create

I haven't added features, and of course I haven't used SSEx4 optimizations for this yet because I only have the one mono loop at the moment...

In any case, to anyone who needs a simple example on using Mem Create/Wave Read/Wave Write to make arbitrary length delays and loops - I've attached a very simple and fairly readable example... plus it includes a couple of my GUI button widgets 😀

flamingRedDingo · 23 Oct 2010

Yet another update: I've finally figured out how to use Mem Create, Wave Write, and Wave Read so I put them to good use...

This new schematic now serves as the basis for my final multi-looper VST...

This is a reasonably efficient variable length stereo looper module, with a partially built user interface. The looper could probably be slightly optimized, but it's already decent in terms of CPU usage, IMO The driver can handle up to 4 independent stereo loops at once without any increase in CPU usage.. The looper itself uses some too though - like I said, it may be able to be optimized but it's already a decent performer...

The code fairly well structured, and readable... (some of the UI schematic is spaghetti, but the core functionality is pretty clean, IMO)

trogluddite · 23 Oct 2010

Looking nice - you're getting good at this seriously fast! Very little left to optimise too, I would say. The driver code could be hand coded in asm a little more efficiently than the SM compiler does it (typical British understatement! - the SM compiler is pants at optimising) - but the amount of code is relatively small, so even that is just window dressing really. Untll (unless) we get dynamic buffers in code, the looper itself looks spot on - shame we don't at least have a mono4 mem read/write. That's why I ended up using fixed buffers - the mem read/write method gets very messy, very quickly if you start adding interpolation, crossfades etc.

BTW. Had a fantastic evening out in Leeds last night - a little mini music festival; all kinds of styles of music, but there was live looping in abundance - Stand outs for me were Juffage and Dosh - both one man bands, using multiple layers of loops taken from their live playing to build up entire tracks - well worth checking out.

flamingRedDingo · 24 Oct 2010

WRT to the Leeds... you make a yank jealous...

here in Seattle we get an influx of good musical talent from around the world. The art seen here is thriving and pretty eclectic... That said, the USA is a by and large, a cultural wasteland... It's not that there are not good artists. With 300million people in our country, you are bound to have some! It's just that the only ones you hear of are the ones Pepsi thinks will help them sell more soda =/ so many of my favorite modern artists are either local to the UK (Mike Skinner, Richard James) or moved there (Reggie Watts)...I guess what I'm trying to say is that I'd love to stay in London for a couple of years and see what some of the art scene looks like at the local level... but then I'd just be another american idiot tourist yank a55h0le... plus I'm not independently wealthy, and I think your country would be upset with me if i was living expat and working for a US corp =P

also, you guys send us great artists - then we shoot them =( (John Lennon)... I for one, don't get it...

As far as the code: I'm glad to see you came to the same conclusion I did when it came to the loop optimization... it makes me feel better going forward... I've got to add some simple effects to each loop (Delay,LP,HP,BP maybe distortion and verb) since Synthmaker doesn't support VST3 side-chaining... and as long as I can convince SM to mask off the paths that are not in use (so they don't operate) I think I can keep the CPU under control... All of this is going to take effort, and so I'm glad to hear that I've got a solid foundation...BTW, if you happen to know how to mask parts (especially code segs) so that they don't actually run unless they are in use, it would save me a lot of experimenting 🙂

Cheers

flamingRedDingo · 24 Oct 2010

I was reading your post again, and something caught my eye this time around:

you said that you don't have mono4 for WaveRead and WaveWrite. This is true, but both in the most common use case and (with careful planning and some limits) in other use cases, you DO have mono2 ... Mem Create/stereo=true, Wave Read and Wave Write have stereo versions... there's no law that says they MUST to be routed as Left and Right channels =)

I think that this is significant because I found myself actually wishing SSE dealt with 2channels at once rather than 4 because it would simplify 80% of the scenarios... (a stereo buffer)

Personally, I'd rather see a better suite of Memory components, like Mem Set/Mem Set Section/Mem Get Section, and/or some sort of Mem Copy component ... also, since we are dealing with SSE4, it might be nice to be able to package a 4xChannel mem create option as well as a 1 and 2 channel mode... I have a suspicion that this *might* be why MemIn doesn't work yet 😉 I think Mem Create won't make an "SSE compliant" buffer directly...MemIn would have to take 2 to 4 Memory connections EACH...

Anyway, as long as I can keep the CPU under control I'm okay with stereo in and out Wave Read and Write...aka mono2 =P... although it may make sense to fabricate a Mono4 wave read and wave write module out of 2 stereo components just to sort of make the code future proof... since Malc barely does updates on SM anymore (maybe it actually IS flowstone now?) ... I for one, don't care to future proof...

Right now my biggest pain point is that the FL Studio DAW consumes about 150MB upon loading a SM created plugin... luckily , it's only the FIRST time, and not 150 for EACH plugin... also FL has NEVER returned the proper time signature info (to any VST, not just SM plugins) ... so all my measurements have to be in beats, not bars...

And as of yesterday, my biggest current gripe with SM is lack of VST3 support.. or at least, I can't get at the features I want (mainly side-chaining).. also it'd be nice to be able to copy one buffer to another at something faster than the sample rate... I can sort of do it, but it's painful and inefficient to do in SM... I could run 4 or 8 concurrent "copies" at once so I am copying 4 or 8 samples at each iteration... but that's UGLY...

Cheers..

MichaelBenjamin · 24 Oct 2010

about sidechaining , try reaper - it offers flexible routing that works nicely with multiple ins/outs

flamingRedDingo · 24 Oct 2010

FL supports side chaining...

and I have reaper ... (the thing for making JS vst effects) the reaJS part is free in fact... trouble is, I just don't like it. It shares a rather large problem with Synthmaker (non-comprehensive documentation), but a smaller community, and the code, while more advanced in some ways than SM, is that much MORE in need of good documentation... I'll probably revisit ReaJS in the future...

Oh, and as promised, I've turned all of the looper stuff into a neat packaged example ... complete with fully working UI and plugin presets, etc... it's pretty polished , but not perfect. That said, it's better (in some significant ways) than those not-quite-free looper VST's out there....

apologies for the FL centric schematic .. I use FL's synthmaker integration since it comes with FL producer =)

should work as a plain VST effect too, but you might need to adjust the schematic...

The looping code is amazingly low CPU (it actually got MUCH LOWER after I did nothing more than put some stuff in a module... I still haven't figured out why, but I'm not complaining!).. if you this doesn't seem right, i think you can probably compare this with my last offering if interested ... if anything, this one is *more* complicated...

I'm going to cross post this in examples as I promised before...

trogluddite · 24 Oct 2010

flamingRedDingo wrote: WRT to the Leeds... you make a yank jealous...

The irony being that both Juffage and Dosh are actually US citizens!

Re: shutting down unused loops. SM can be quite clever about this 'under the hood' - stream modules/primtives (including code/asm) will be shut down whenever they have no active output, and this effect 'daisy-chains' upstream - so a stream primitive that itself only outputs to dormant modules will also be shut down, and so on. So by connecting those 'dummy' outputs on the wave write via selectors, you are able turn them off.

(BTW, using the purgable readouts in your schematic may make problems for VST export - they will be purged from the export, leaving the wave writes disabled because of no longer having an output - I tend to use M2F's because they don't consume CPU unless they get a green trigger - but they do satisfy the 'having an output' condition for the writes to be active) You can then do similar with the wave reads to shut those down. The driver code will then also shut down once there are no loops at all running. The only thing to watch is that the switching forces a 'recompile' of the schematic, which will force all code components to stage(0)

Stereo = mono2; spot on, a channel is just a channel, I've used them for Mid/Side etc. in the past - but I'd still love a true 4 channel read/write, partly for neatness, but also because the CPU load of the packing/unpacking builds up if you need a lot of them - I saved a significant chunk of CPU load in Soopa Loopa by asm coding my own hopped pack/unpack modules - It would be nice not to have to do the mono<->mono4 conversions.

Part of the reason for the strange memory usage is down to the way that SM plugins are compiled (though this may be a little different in the FL version). Exported plugins are actually a copy of the schematic plus a 'GUI free' copy of the SM compiler - the schematic is then 'rendered' when loaded into the host. AFAIK that's because the support for tracking green triggers, analysing the CPU saving mentioned above etc. is required for the plugin to run, and it enables some CPU specific optimisations when compiling. Also, most primitives remember their current state when saved/exported - so memory greedy stuff like mem's, arrays, bitmaps etc. don't necessarily reload in a 'zero'd' state, they will be whatever size you had them when you pressed the save button. Mostly that's quite handy - bitmaps for knobs etc. are saved within the plugin, and you can make their file loaders purgable - but for things involving e.g. sequential logic, it can be worth using the 'On Load' primitive to reset them; otherwise they might load up containing odd 'legacy' values from your last editing session.

flamingRedDingo · 25 Oct 2010

Thank you for that! This is really really helpful.

Regarding resetting the code to stage 0 ... funny, I was actually wanting to "force" this on certain events (like to reset my "loop driver" after wave load returns 2=loaded =) So as you said I will be careful... but I'm also looking forward to exploiting this behavior...

I appreciate the explanation for how mono lines are shut down. It really helps explain why the Wave Write primitives needed my little (mistakenly purgable) shim.. the reason I made them purgable was because I first thought that this was a necessary "hack" and that SM didn't actually need the hookups to live beyond export... at least that was my hope... I hadn't really tested it fully, but I suppose I should update my loopers to do this properly. Thanks too, for the mono to float trick... I wasn't sure about it before...

BTW, not that it matters, but I am not technically a "registered user" of synthmaker... since I have fl studio, that's how I came by my SM "registration"... therefore, I haven't actually looked at your bits in the registered user portion of the forum because I don't have access...

trogluddite · 25 Oct 2010

I would say that FL counts as registered in my book - a licence fee of some osrt must pass from FL to the SM guys as some part of the deal they have. If want to PM me your e-mail, I'll mail the latest version schematic to you as an attachment. I just tend to keep my big project schematics as 'registered only' because the regulars here on the forum are a trustworthy bunch - I'd just rather not see some idiot with a pirate copy of SM getting nice goodies for free, when I have paid my licences in order to make that plugin.

flamingRedDingo · 26 Oct 2010

Argg!!

I was all proud of myself because I figured out how to make a stream copier with a DoIt trigger...

Then I wired it up and everything went crappy...

Seems that wave read/wave write primitives don't handle concurrency (threading) properly... when I use more than one each on a stream at various indices, I get noise and it locks my DAW up sometimes... which is also how I managed to lose my clever little copier thing... I should have saved...

trogluddite · 26 Oct 2010

flamingRedDingo wrote: Seems that wave read/wave write primitives don't handle concurrency (threading) properly.

Maybe that's why the write is an 'R&D' primitive? Multiple reads should be OK- they're used that way often in interpolation modules etc. I have had one schematic in the past that was funny with the wave write (only one write in the design) - load it up, enable the ASIO, instant crash - but, load it up, add a mono readout (not even connected to anything), delete same mono readout, enable ASIO; absolutely fine - never did work that one out, but it always worked fine as an export. Don't know enough about SMs internal functioning to know how it handles its threading, but I do know that execution order can be a problem sometimes with this kind of thing - there's no control over the order in which primitives execute, and it doesn't follow any logical input->output flow or anything similar. Most of SMs delays are coded using combinations of stages 1,2 & 3 to gain some control over execution order when chaining them. No idea if that may relate to your bug, but thought I'd mention it as it is a similar situation of passing the output of one buffer to the input of another.

flamingRedDingo · 27 Oct 2010

I may have to remove the "Step" knob from plate monkey... I don't want to bounce between two loops at two different step rates... hmmm.. as I was writing I thought of a way to make it work, but it wouldn't be "step neutral"... I wanted bounce to be 100% setting neutral... buffer to buffer at 1:1 rate ALWAYS... I'll have to try some stuff.

You mentioned that you wrote your looper using a fixed buffer because of (if memory serves) CPU constraints...or something, forgive me if I'm a bit fuzzy...

In case you hadn't noticed, I happened upon a surprisingly efficient and flexible dynamic looper module... it allocates and deallocates RAM &&& CPU on demand, and the CPU load is low already (and can be lower still I think, by simply disconnect the stream outputs on the Loop Driver)...

Based on my rough reckoning, it's at least as efficient as the fixed buffer methods I was using before.

So if I were you, I'd give it a look...

trouble is, it can be hard to integrate and learn widgets made by others, but here's a simple IN/OUT single stereo loop, all wired up and encapsulated nicely... and it is efficient...

also I know I'm being presumptious that you'd be interested in my engine, but I'm offering it because I found the fixed buffers to be such a nasty bother (even makes 44.1 vs 48 operation painful)... I can't help but wonder if you'd like it to be dynamic too if you can get away with it...I'm not sure if it can be tweaked to fit your requirements, but since it is so powerful, I thought it'd be worth passing it along.

You are more than welcome to take it, and do what you will with it...of course, it's the latest revision I use in PM...

Cheers...

trogluddite · 27 Oct 2010

I'll certainly be going over your designs with a microscope! And I will certainly be adding your final release to my song making toolkit!

My main reason for using fixed buffers was to keep the loop engine all inside one code module, partly for ease of programming and partly to keep the execution order under control. Mainly that has to do with keeping the audio as smooth as possible - due to using interpolation to allow fully variable speed, and the use of crossfading to avoid clicking at the loop points and parameter changes, I would end up with a schematic with a dozen or more wave reads per loop. Not impossible to do with mem read/write, but very messy and harder to maintain.

As the looper was written purely for my own use (though it's always nice if other people want to use it!), I was free to decide that any impact on CPU/memory usage was a reasonable compromise for me. I see it largely as a stand alone application (in fact I would like even more to try using FlowStone to turn it into a hardware unit) - so I've no intention of running it alongside dozens of other plugins etc., and the CPU/memory requirements are (for me) not excessive (I've had it running beautifully on my old P4 with 1GB RAM). Similarly, I have absolutely no need for running it at anything other than 44.1kHz - without using far more complex interpolation etc. the audio qualilty really wouldn't improve much anyhow.

Of course, further optimisations are always good when you can implement them (many 'newer generation' programmers seem to neglect this terribly, never having had to use a computer with a 4MHz CPU, and 16kB RAM!) - but to be honest, I've little intention of doing a big rewrite now (unless we see proper code/asm 'mem' support) - it is functioning pretty much exactly as I like, and I want to get on with using it to make tracks, and concentrate my SM time on other projects.

flamingRedDingo · 27 Oct 2010

Ahh...

well, there you go. I can't argue with that (and wouldn't if I could)

you mentioned Interpolation using multiple wave reads - very clever - i can picture it ... I know you aren't employing that technique, but *I* might =P

You may have just contributed to my design again - even if inadvertently.. If i wasn't going to be hopped up on painkillers and missing a couple of my teeth in a couple hours I would tinker with the idea....

I actually have been looking for a good interpolation/resampling technique to use with PM, and since I plan on changing how the stepping works anyway I was hoping to get it into my next release... thanks!

trogluddite · 27 Oct 2010

No problem! Good luck with the teeth.

oddson · 27 Oct 2010

flamingRedDingo wrote: ...you mentioned Interpolation using multiple wave reads - very clever - i can picture it ... I know you aren't employing that technique, but *I* might...

There's a very simple linear example in the stock wave-player.

I've been doing long-delay projects with feedback since I started with SynthMaker and I never occurred to me to use the memory-buffer components (although i don't think they existed when I started).

I'm wondering if, other than greater flexibility and less memory usage, are there any other benefits to this method?

trogluddite · 27 Oct 2010

oddson wrote: are there any other benefits to this method?

One thing that does spring to mind is that using the 'mem' buffers ought to make saving and loading of the buffer contents possible.

flamingRedDingo · 28 Oct 2010

Definitely, it makes loading possible.

It *can* make saving possible, but there might be a catch...

To make true recording capability, one would need to open a RIFF/WAV and keep it open whilst recording, continually feeding it data AS IT COMES IN... I haven't investigated, but I don't know if that is possible with SM... it is with SynthEdit (I've seen SE based plugins that do just that)... Recording isn't just a matter of being able to save a wave. You must be able to write to the open file with an indeterminate and continuous buffer...

flamingRedDingo · 28 Oct 2010

oddson,

Personally I find that simply being able to elegantly handle 44.1k vs. 48k samplerates is a good enough reason to use the memory buffer approach.... your option(s) are not good when using fixed mem.. .you either have to tie your creation to a particular samplerate or allow some of your precious RAM to go unused in your fixed buffer to accommodate the various sample rates...

Looking through SM's stock stuff, I've seen that the SM widgits are usually geared for operation at 44.1k... Since I run at 48k half the time and 44.1k half the time, it keeps me honest... I want my plugs to handle both situations with grace. =)

The question I've continually asked myself when coding the dynamic buffer delay/looper was "how does this compare to my fixed mem version, in terms of performance"...

My testing has led me with the conclusion that, while running and recording, I achieve approximately the same level of CPU usage with each implementation, but there's a tiny bit more room to optimize in the fixed buffer impl...

In the end, that leaves the dynamic buffer as the clear winner in terms of perf .. because I can turn it OFF when I'm not using it, but they are pretty much equal when they are on...

trogluddite · 28 Oct 2010

flamingRedDingo wrote: keep it open whilst recording

Ah yes, I was very careful to say saving 'buffer contents'! The kind of streaming you mention is indeed not possible in SM (though I have requested it). All the same, being able to save the buffer contents (i.e. contents of a loop - for which the length is already determined), would still add the useful function of saving a recorded loop for loading into another loop slot or a new composition.

I considered using mem buffers in the early stages of Soopa Loopa for precisely this reason. The downside, that I only realised once I got started, is that the buffer size must be predetermined before you press record - AFAIK it can't be dynamically resized during recording. Because Loopa relies on a button press at the end of recording to determine an arbitrary length, I was always going to be stuck with just having to reserve a big chunk of memory knowing that it would rarely be fully used. Damn! - bring on the streaming, I say - that could potentially solve so many problems - a short buffer to prevent latency would suffice, bouncing and loop duplication would be so much easier - and no need to run a seperate application just to record the final mix!

flamingRedDingo wrote: but they are pretty much equal when they are on...

Depends very much on how you use them, and the level of complexity re: interpolation/crossfades etc. - if you have many loops running at once, the ability to optimise for mono4 makes fixed buffers in code/asm more CPU efficient as there is no need for packing/unpacking the reads/writes or using multiple code blocks (though the buffer read/write operations themselves are probably about equal as it has to be done one channel at a time anyway even in assembly). OTOH, if you want to use multiple instances of something simpler (for example, several tracks/instrumentalists each with their own independent looper) then yes, the flexibility of the mem method wins hands down.

But then that's what makes SM so great - being able to match the implementation to the concept. (and being able to have intelligent debates about the conceptual side of DSP!)

flamingRedDingo · 28 Oct 2010

absolutely.

I wasn't necessarily attempting to undermine the fixed size thing. In fact, at first I figured that it was the way to go.

And I have in fact ran into the problem you mentioned with respect to being able to non-destructively reallocate the loop buffer . Doing something like what angstrom lets you do (double the loop length while playing) is indeed challenging with the dynamic loop mechanism. While I've got a theory on how to make it work without a reserve buffer, I have yet to be able to put that theory in to practice. That speaks volumes as to the flexibility of the "fixed mem" solution - doing the doubling is a no brainer with your method... Right now, I have to do doubling with PM by copying one loop to a longer loop using the mix function, which is wasteful and unpleasant =P...

Cheers 🙂

PS: Apologies if my post(s) lately have come across as judgmental to your technique, trogluddite. That was not the spirit in which my observations were offered, and was never my intention. Sometimes I'm guilty of misrepresenting myself on a board because I get excited and fire off a post without re-reading it. Just so I'm being clear, I highly respect your insight, your helpfulness and your abilities with SM.

trogluddite · 29 Oct 2010

You have nothing to apologise for - the respect is mutual, and the tone of my posts has possibly been a little more defensive than I intended. I'm really enjoying this thread, it's all too rare to find someone to have a real exchange of ideas with - going beyond just swapping 'top tips' and getting into the more abstract ideas about how to approach the programming challenges we run into. I've no problem with people getting a bit 'evangelical' about their discoveries - if there is no enthusiasm there, then the play and creativity are lost, and life just becomes a list of chores to tick off. As far as I can see, all the assertions you've made about the advantages of your programming method have been backed up, both by your reasoning and by by your schematics (theory and practice)

Seems to me that there is actually far too little arguement in the world today - in the true sense of an open minded debate without the expectation a consensus having to be found. It's far too easy to step away from such things for fear that arguement implies conflict or aggression - or to take the easy option and follow the herd instinct into just accepting the majority opinion. Truly a recipe for a stagnant society full of easily manipulated people who can't even justify their 'beliefs' to themselves.

Besides which, I'm guilty of some real humdingers of posts in the past (and probably will be again) - for some reason I have many of my best brainwaves whilst a little drunk etc. - at least, I think I do until I re-read them the following day!

Whatever the pro's and con's of our different methods for making loops, the things you're doing with the mem read/write have carved out some new territory to explore in Synthmaker (as Oddson hinted previously). While they may not suit my vision of Soopa Loopa, they will unboubtedly become part of my 'armoury' for tackling future projects.

MichaelBenjamin · 29 Oct 2010

trogluddite wrote: Seems to me that there is actually far too little arguement in the world today - in the true sense of an open minded debate without the expectation a consensus having to be found. It's far too easy to step away from such things for fear that arguement implies conflict or aggression

good point to contradict this in its own spirit: everthing is good as it is. the virtue is patience, so it is to accept the amount of argument and the amount of fear it causes based on irrational assumptions at this time. you cant change nothing. everything has already been decided.

oddson · 29 Oct 2010

thanks to both of you... very interesting thread (at least the part of it I actually read).

...and the falling all over yourselves to avoid offending is nice too. 😇

I'm going to stick to fixed memory (for now) for the following reasons.

1) RAM is cheap/CPU is dear: I don't know about you but I always end up maxing my machine's RAM as the machine moves from 'new' to 'time to get new one'. I've got plenty to spare in most of my music-creation situations (especially in the eXT v.1 setup I use for most of my looping performances). I've used four independent channel delays in all my projects since pretty much the beginning so the CPU savings outweigh (in my opinion) the RAM costs.

2) Sample Rate is just more RAM: Since I'm waisting RAM already I'll just waste more for higher sample rates. Mostly I use 44.1 kHz but even when I no longer do I'll still be OK with squandering RAM. (I could even use nearly identical code blocks with different array sizes for each potential sample rate and dynamically select the active one using the current sample rate. The same trick could be used to give optional max-delay times to limit RAM use. Then only the code storage in the dll would be 'wasted' RAM.)

3) Money back guarantee: I don't do commercial development. So if my wasteful ways offend then don't use my stuff. Mostly I don't even share my work; it's for my own music making.

4) Interpolation and conditional filtering is easier and cheaper in code arrays: I've made jumping tap points an integral part of my delay projects and some kind of filtering to get rid of the discontinuities in the signal is essential --but only for a few samples after a change. I don't know how I'd do this with the memory-buffer primitives. Similarly for interpolation of the signal which is pretty much required when you add time effects like flutter and shifting- (as opposed to jumping-) tap points.

Still it was fascinating to see this approach and I'll keep it in mind for the future.

Great to have you in the community fLD. 🙂

oddson · 29 Oct 2010

5) The host can do the recording: I don't see the point in saving the files directly if the host can save the output. I forgot that one.

trogluddite · 29 Oct 2010

oddson wrote: ...and the falling all over yourselves to avoid offending is nice too. 😇

He he, it's a great old British tradition - we even apologise for the weather if it rains on a picnic we arranged three months in advance! Watching two Brits reach a doorway at the same time can be highly entertaining as they both stand there for five minutes each insisting that the other goes through first.

flamingRedDingo · 29 Oct 2010

trogluddite,

you could say the same thing about two Canadians in a doorway. =) In my neck of the woods (northwestern tip of the US) we see a lot of them, eh? =)

oddson,

all very good points. if you need to do array based ops like filtering, fixed mem *is* better.

WRT to plate monkey, I'll continue to use the dynamic approach because I want my loop lengths to be widely variable without wasting ram - right now each of the 4 loops can be 1 to 128 beats in length, and I'll probably double it to 256 to compete with angstromlooper... I may also add up to 4 more loops to PM... the fixed mem solution (even if I were to subdivide the buffer like I did on my initial implementation) would absolutely kill my RAM...

also oddson, and maybe this is just my setup... but I've got a wolfdale E8500 core due with 2gb of ram... I could add another 2, but I'd have to switch to a 64-bit OS to take advantage of it.... believe it or not, I've never come close to maxing my CPU in my DAW, not since I got rid of my old machine =)... RAM on the otherhand, is very dear to me... try running 4-6 instances of Kontakt each loaded with 61 samples at at least 2 bars in length a piece... RAM is dear to me. CPU, not so much...

Regards

flamingRedDingo · 29 Oct 2010

I'm gonna have another go at my last post.

Since I do a lot of sample and loop heavy stuff, and very little synthesis (I probably never load more than 10 synthesizers into my programs) even if I use tons of FX, but I use samplers a lot (hey - they just sound better than my FL Slayer guitar synth!) maybe that is the reason RAM is more dear than CPU to me...that, and I can't seem to tax my CPU no matter what I do in my DAW.... thank God above for the death of the Pentium 4 !!!! I love intel's newer lines... I can't tax them. not with real world use... I just can't... of course, that makes it harder for me to evaluate my plugin performance WRT to CPU usage (what's that 1% spike look like on a P4, or a subpar AMD???)

That said, I really need to switch to 64bit so I can use more ram... It's just that I've run my current windows setup since I initially installed it on a PENTIUM 3!!!)... that's got to be some kind of record... anyway, between getting my wisdom teeth yanked, and starting my installation over from scratch, I'll take the former... =P

Cheers,