Zebra PC blog

[lightyear]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

See, my problem with all these third party libraries is, they are all a bit super potent for what we need and it takes a lot of time to study & adapt them. It's not like you download the sources, compile and go.

Totally got that. On the other time, those of us who are your intended target audience get the benefit of using a language that we can go buy a book on. It's not like we're just going to download your plugin, compile our own scripts, and go.

I'm just another programmer wondering whether I've got to learn yet another language, and I'm feeling language fatigue.

E.g. it was shocking that adding support for .aupreset on Win has more than doubled the size of the binary, using open source projects. So I left it (XML parser and some CoreFoundation stuff...) away until I have time to write my own 2kB converter, instead of 900kB of redundant instructions. Which cost me a couple of days to find out.

Well, there's always TinyXML; that's what a lot of xplat people with micro-sizes in mind tend to lean on. http://www.grinninglizard.com/tinyxmldocs/index.html (http://www.grinninglizard.com/tinyxmldocs/index.html)

And honestly, I always wanted to write my own vm.

Sure, but now the whole VM rests on your shoulders to debug. Is this going to be one of those things that's complicated enough to work brilliantly for you while you're building it, and then cause you billions of hours of support in the wild? Will it all have been worth it if it did?

Having shipped an awful lot of bugs in my lifetime, I just don't tend to look at things the same way anymore.

For instance, for a lot of things, especially dsp stuff, it's necessary to "patch" right into the engine.

Yup, and I can totally see the value of that. If a pure internal-object-equals-external-object API isn't good enough, then you're either restricting your usage of your internal mechanisms, or requiring that you think about your internal design with a mind to how you want its API to be used externally - either of which can be limiting.

On the other hand, object-for-object bridging is pretty cheap and easy to do in most VMs; and integrating the code to bridge the divide is well documented in most of the popular runtimes.

Stuff like that only works when you can be sure that nobody else changes anything.

So lock a branch, freeze it, and ship your own that doesn't shift around underneath you; you still get the benefit of standing on the shoulders of others.

I'm just playing devil's advocate, here. The reality is you're doing it because you really wanted to do it, and that's the only good reason to do anything anyways. It does strike me, though, that if you never depend on anyone else's code, then you're never going to benefit from anyone else's implementation. That's a huge burden to wear when you're trying to keep it light and fun and generate new high-level ideas instead of getting neck-deep in the low level ones.

That is, when you've written it yourself. If you need to upgrade a 3rd party lib, i.e. because of platform issues (Intel Macs anyone? Or 64 bit architectures?) you can be sure that you have to spend a lot of time into redoing a lot of changes. Maybe I'm paranoid here, but that's just how I see things.

And it's true.

Sure, that happens. But the other thing happens, too - this thing does X, and while I hadn't thought of it to start with, using that gives me Y, which is a cool thing. And I get to work on implementing Y, instead of all of the ugly guts of Y that are ultimately just mindless drudgery.

Last but not least, I had great fun writing the parser

And there we have it. The reason.

(Writing the VM was more like a bad joke... it's not much more than a file with 200 callbacks that consist of 3-8 lines each. It was done in 6 hours or so.)

So far. Having been neck deep in an attempt to port a DS emulator to my mac, I can attest to the fact that they start out looking really, really simple. However, it does strike me that if you're going for that kind of model, having a nose around other people's game emulators might be a good place for you to find some interesting methodology for your VM.

Anyways, nice chatting. Good luck, and I hope to see a final version of the plugin soon.

[Urs]

those of us who are your intended target audience get the benefit of using a language that we can go buy a book on. It's not like we're just going to download your plugin, compile our own scripts, and go.

Hehehe. You won't have to buy a book for that. It's plain C without pointers, unions and structs, restricted to the types of int and float with their respective arrays. No chars, no strings, no doubles, no shorts, no longs, no unsigned anything. Oh, and no labels for now, thus no switch nor goto. No void return type. No stdio nor stdlib, but a lot of maths (sin, cos, log, pow, abs, max, min, sqrt, etc.)

Wait. There are structs. These are the pre-defined objects. Just like the period-based object notation in Java/JavaScript.

Believe me, if you have ever touched C or JavaScript, you won't have any problems here.

As for stability... wait and see. Hehehe, I had one of these weird bugs yesterday. A char beyond 127 must have slipped into the source of a test script. I'm filtering these now

I think the question is not the richness of general purpose languages. The richness is defined by the offerings of the plugin. The language is just an addendum to programatically add some synapses between the stuff that's already there.

Honestly, I wouldn't expect that more than 5 to 10 users really get into this. But even as few as 20 useful scripts, with a couple maybe being interchangable with my other plugs, can already add enough comfort to the plugs that justifies the effort.

An intrigueing insight is that the scripts can offer functionality across module borders. That's something that I can't built into the plugin itself unless I violated my strict rules of modularity. In Z2 for instance no oscillator is aware of other oscillators or even of filters or anything. The Grid just knows who's inside, but it doesn't know what an oscillator actually does. But the author of a script (or patch...) knows a lot of things about the stuff...

Mhmmm...

Cheers,

Urs

[Urs]

More news from the geek side...

... and good news they are!

The virtual machine is full featured now! Today I implemented & debugged the last weird bit of basic functionality, namely the possibility to write recursive functions.

Here's a little script I wrote for testing:

Code: Select all

float a = 0;
float b = 1;

int count = 0;

float testFunc( int inOne, float inTwo, int inPotenz )
{
	if( inOne >= inPotenz ) return (inTwo);
	
	count++;
	
	inTwo *= 2.f;
	
	float out = testFunc( inOne + 1, inTwo, inPotenz );
	
	return (out);
}

a = testFunc( 0, b, 16 );

As expected, count is 16 and a is 65536.0

I've also finished object bindings for MSEGs, oscillator wavetables and Grids. Well, all "normal" parameters are accessible anyway. I'll add some more (less important) bindings (tuning tables, key/velocity scalings, LFO userwaves, spline-based oscillator shapes) when I feel like it.

Sure, there will be some bugs. But I guess it'll be hard to make it crash, so that whatever bugs remain in the VM, it will only lead to unexpected behaviour, or merely, to error messages.

The next few days will be spent on these things:

- transistion to the externally developed filehandling (yes, it just arrived in my mailbox! WOOOOT!)
- add .tun file import based on new filehandling stuff
- graphics for the Modulation Mixers (I almost forgot to add them to the gui...)
- VST2.4 support

And then we will happily say: It's full featured!

So, we'll soonishly have the chance to do some more beta testing soon, clean up, make screenshots for the manual, add hundreds of new prestes to the factory lib, come up with a proper website, make installers, celebrate

Can't wait to get to the point!

Cheers,

Urs

[twolegstoneworks]

Definately time for some celebration!

[brok landers]

urs, da wart ich echt drauf, bin total gespannt ...

[Sargon]

Will there be a book like "Zebra for Dummies" for it? I think I will need it badly ...

Greetings,
Michael

[Urs]

Will there be a book like "Zebra for Dummies" for it? I think I will need it badly ...

Not really. Even though some geek aspects enter the stuff, Zebra will remain usable the same way it is now. In fact, the whole scripting thing will be quite invisible. Only, some presets will do things that presets usually don't do and they'll sit in special directories. No need to be scared

There'll be different kinds of such scripted presets. Some will act like normal presets, i.e. "intelligent" randomizers. Others will act like editing tools that offer features beyond the stuff that's built into Z2. For instance, I often experiment with the arpeggiator only to find out that I get a cool groove, but the perceived downbeat is not on the first note, it's somewhere in the middle. Instead of doing the tedious job of manually copying all arp steps into the right place, I'd rather write a scripted preset that moves them one step left or one step right. Then one just loads that preset a couple of times until the downbeat has reached its position.

Or, a really geekish example: Some have requested that the Arpeggiator should be constrainable to a certain scale, such as D-minor. Well, that's something very low on my priority list. But it can be done with the means that are already there. I've planned to come up with a script which takes the last key you pressed and sets up a tuning table (normally used for alternative tunings) that moves the "black keys" within that scale to the appropriate "white keys". Then the arpeggiator will always be in tune, regardless of how complex it might be set up. The advantage of this approach: You're not limited to major or minor scales. Scripts can also be written to accomodate pentatonic constraints or anything. - The effect can be reverted by simply switching off alternative tunings, or by loading the default Welltempered tuning table.

These examples are just a tiny fraction of what's doable. The interesting part is, I can add functionality that accommodates "special interests" without having to clutter the gui with academic noise.

Of course, there'll be docs about making your own scripts. I'll keep them small and separated from the actual Zebra website, because it's something that only a few people will bother with. No one needs to, but he can if he likes. The major part of the documentation will be the thoroughly commented example scripts that come with Z2 final, such as randomizers, waveform generators, XY setups.

Cheers,

Urs

[Urs]

- transistion to the externally developed filehandling (yes, it just arrived in my mailbox! WOOOOT!)
- add .tun file import based on new filehandling stuff
- graphics for the Modulation Mixers (I almost forgot to add them to the gui...)
- VST2.4 support

Point one - transistion to the externally developed filehandling - is nearing completion. Almost through, almost through... just a final little bug that lets the scripting behave weird when there are multiple script sections embedded in a preset... shouldn't be too hard anymore, should it?

Later,

Urs

[Urs]

Point four - VST2.4 support - has caused me sweat and tears, but it seems to be working, at least on the Mac. Will test Win later today or tomorrow. On the other hand, it's mostly needed for Intel Macs and Win64, so maybe I should stick to VST 2.3 on Win32 for now...

.tun file support is almost done, but I havn't touched the graphics yet. We'll see...

Cheers,

Urs

[wrench45us]

it's like an underground revolution that's about to poke it's head into the world's evening news, eh?

just keep it under the headphones till it's ready.

[beej]

Just loaded the most recent beta (I've kinda been away from Zebra for a while) and had a quick play with the arpegiator - very nice indeed! I'll save all my most stupid questions until the manual page is written except for one:

Does the arp *only* run when the mode is set to "Arpeggiator"?

In other words, can the arpeggiator be running so I can arpmod various parameters, *without* arpeggiating the played notes? Or should I just forget the arp and use the multistages for this?

[rsmus7]

Does the arp *only* run when the mode is set to "Arpeggiator"?

In other words, can the arpeggiator be running so I can arpmod various parameters, *without* arpeggiating the played notes? Or should I just forget the arp and use the multistages for this?

atm the arp runs only when its set to "Arpeggiator"
at least as far as I know.

[beej]

Ok cool, thanks.

[Urs]

There's a feature request to have the Arp running even if it doesn't control the notes. I love that idea, but the code is so complex already that I wouldn't wanna touch it right now. I'll unleash the Arp from ArpMode in a subsequent update!

Later,

Urs

[beej]

That's cool, cheers Urs. It's not a vital feature at all, but it would be cool if you could route the arpeggiator in a similar way as the other modules.

You could then do stuff like having the arpeggiator do standard arps on a pair or oscillators, while a second pair of oscillators is not arped to make an underlying pad, with the arpmods doing some wacky stuff on the pad.

Maybe even have multiple arpeggiators for different oscillators!

Lots of opportunities for coolness!