u-he

dmacintyre · Post by **dmacintyre** » Thu Jul 19, 2007 9:57 pm

I agree with Urs. The NI model is flawed IMHO because of the subjective nature of metadata. Lightroom / Aperture uses photographic metadata which is a bit more focussed (no pun intended) as a predominantly blue image can have a tag "blue" and it will be so constantly and to all users as blue is blue throughout the world. But labelling a patch "bass" or "lead" is a bit pointless as it's qualities depend on what octave / register you are playing it in and how you are playing it. OK, you can subdivide arpeggiated / pads / percussive / etc, but that how things are done already in most synth patch lists anyway. No, IMHO the most important thing for a synth is sound quality, closely followed by reliability and efficiency, closely followed by preset quality, closely followed by flexibility, etc, etc.

Personally speaking, I think the big money will be for whoever comes up with the first accessible and comprehensive guide to synthesized sound design. Rob Papen is working on a DVD at the moment and if I had the expertise and time I'd be competing with him to get a "Programming Synthesizers for the Masses" video tutorial online. Come on Urs / Howard and, for that matter, Rob

Sargon · Post by **Sargon** » Fri Jul 20, 2007 6:03 am

I agree that the (over-)sophisticated NI solution should not be copied into Zebra. But on the other hand, some metadata for patches would be appreciated: author, creation date, last modification date, notes etc.
A simple text field for some notes would be of much use, I think.

Greetings,
Michael

Urs · Post by **Urs** » Fri Jul 20, 2007 10:02 am

Sargon wrote:A simple text field for some notes would be of much use, I think.

Sure, some simple stuff is easy.

Will keep on thinking in that direction...

mcl dagaz · Post by **mcl dagaz** » Fri Jul 20, 2007 12:29 pm

Working as a data/information architect I love metadata! Well.. kinda.

I want to see the use of ontological forms of metadata (qv OWL) to assist with preset organisation. The basic hierarchical structure that we see today would/could be the starting point - no change. However such a metadata system would allow us users to tag presets in such a way that it reflects our idiolect.

Developing an equivalent standard 'business vocabulary' for sound designers would be rather difficult I suspect

A formal and standard ontology for sound design seems very unlikely... but building up from your personal view in a way that say delicious does and using those tags to facilitate navigation would be excellent. The storage mechanism might OWL or something else... it is this social tagging and the networking of those tags that delivers the value to folks like you and me.

Using an interconnected set of sound designers each labelling their sounds and building a 'folksonomy'... well that would be very welcome indeed. That has got to be doable surely?

Then again, given the choice of better and improved VSTs or a diversion like this which would we rather have? Metadata or not, I would rather the focus was on the core of the VST design.

But I suspect that sooner or later someone will get into using semantic approaches for sound design metadata. When they do, it will be awesome.

Urs · Post by **Urs** » Fri Jul 20, 2007 1:54 pm

mcl dagaz wrote:But I suspect that sooner or later someone will get into using semantic approaches for sound design metadata. When they do, it will be awesome.

I don't really think I understand what you just posted, but it sounds interesting...

As can be seen, a lot of work on my side recnetly went into patches: Improvements to patch browser, faster patch loading, gui remembers patch/location, Midi Program Changes planned, collapsable directory structure planned, support for longer filenames in module preset browser, improvements/fixes to patch scripting engine etc.

It's unfortunate that I hadn't had this complexity in mind when I started the engine a couple of years ago. I have obviously been too focussed on complexity/modularity management, cpu optimization and interface design. Changes to the patch organization are tough. Even though the patch browser seems rudimentary, the underlying structure is not. In fact, I think the patch organization already exceeds 20% of the overall code.

I assume that an "intelligent" solution which has to maintain a database would be a serious enterprise. Just look at the memory side: Zebra's memory footprint for patches currently consists just of the directory tree and the list of patches within the current directory. That's quite easy. But considering that there are nearly 4000 patches available already, maybe more than 10k within a year or two, a database will have a serious amount of data to crunch, and probably keep in memory. Or, it needs a sophisticated file access scheme, much like sample streaming...

So, d'oh... we'll see where it goes...

Cheers,

Urs

Howard · Post by **Howard** » Fri Jul 20, 2007 1:57 pm

About the paradox of choice:
http://www.ted.com/index.php/talks/view/id/93

mcl dagaz · Post by **mcl dagaz** » Fri Jul 20, 2007 3:43 pm

Urs - yeah I think the kind of thing I was talking about is very much aspirational and I suspect that it would have to be independent from any VST/VSTi... and work via an API. No idea how feasible that is - I know nothing at all about the limitations in this respect of the VST standard.

Besides which I think you are rightly focused on 'complexity/modularity management, cpu optimization and interface design'!

I have collected (tagged) many articles at delicious for my own research purposes. Some here: http://del.icio.us/mikeCL/tagging

This article is a reasonable one: http://www.iskoi.org/doc/folksonomies.htm

Be warned though it tends to be all a bit dry and academic!

More realistically(?) can we have the mouse wheel change parameters on MFM2, Zebra etc? I.e. hover the mouse over a control for 'focus' (or click for focus) and then wheel away.

It surprises and frustrates me that we have this rather obvious control device on our mouses (sic) and most of the time we cannot use it for adjusting parameters on the vast majority of audio software.

tboulette · Post by **tboulette** » Fri Jul 20, 2007 3:44 pm

Urs wrote:It's unfortunate that I hadn't had this complexity in mind when I started the engine a couple of years ago. I have obviously been too focussed on complexity/modularity management, cpu optimization and interface design.

I would say that your focus has resulted in what is on most folks' short list for best virtual synth ever. I would also say that, as nice as snazzy patch browser/organization/metadata/espresso-making facilities would be, all of that is far secondary to the SOUND, the balance achieved between options and ease of programming, and the efficiency of the engine.

Now, as much as I'd like that espresso option

, I wouldn't want to trade any of that for it. Just my $.02....

jupiter8 · Post by **jupiter8** » Fri Jul 20, 2007 3:54 pm

mcl dagaz wrote:
More realistically(?) can we have the mouse wheel change parameters on MFM2, Zebra etc? I.e. hover the mouse over a control for 'focus' (or click for focus) and then wheel away.

It surprises and frustrates me that we have this rather obvious control device on our mouses (sic) and most of the time we cannot use it for adjusting parameters on the vast majority of audio software.

That works on Z2 on my computer.

Urs · Post by **Urs** » Fri Jul 20, 2007 4:09 pm

jupiter8 wrote:
mcl dagaz wrote:
More realistically(?) can we have the mouse wheel change parameters on MFM2, Zebra etc? I.e. hover the mouse over a control for 'focus' (or click for focus) and then wheel away.

It surprises and frustrates me that we have this rather obvious control device on our mouses (sic) and most of the time we cannot use it for adjusting parameters on the vast majority of audio software.
That works on Z2 on my computer.

Yeah... it should work... even without "focussing" the control...

It will however be optional at some point... I'm gonna try to make some behaviours customizable, such as modifier keys, control focus (for keyboard input) etc...

That and skin support... when Zebra 1.0 came out, people were complaining about the waste of screen estate. Zebra 2's screen is exactly the same size but now people complain how it's too tiny. Sigh...

Later,

Urs

djsubject · Post by **djsubject** » Fri Jul 20, 2007 4:48 pm

Midi Program Changes planned,

Subz

mcl dagaz · Post by **mcl dagaz** » Fri Jul 20, 2007 5:01 pm

Duh. Never thought to try it

heheheh

jupiter8 · Post by **jupiter8** » Fri Jul 20, 2007 5:11 pm

mcl dagaz wrote:Duh. Never thought to try it heheheh

It came as a surprise to me too when i discovered it.

Urs · Post by **Urs** » Fri Jul 20, 2007 7:35 pm

Somehow the Scrollwheel is a bit slower on Win than on MacOS X... that's another thing that should be fixed by an option...

Urs · Post by **Urs** » Fri Jul 20, 2007 9:07 pm

Btw... it looks like Receptor compatibility is finally achieved!

The latest bug that prevents dialed values from being shown in the display is also ironed out here.

Other than that most improvements & bug fixes are confirmed to work.

Just the MSEG bug is still at work. Bummer.

It's still exciting... half a year of really dumb and almost invisible (nonetheless necessary) work has pretty much found an end...

... even though not all improvements are in there. But those that come are probably more fun to compute...

Urs

u-he

KVR Audio

Improvements!