Improvements!

[Howard]

it looks like Receptor compatibility is finally achieved! ...[snip]... It's still exciting... half a year of really dumb and almost invisible (nonetheless necessary) work has pretty much found an end...[snip]... even though not all improvements are in there. But those that come are probably more fun to compute

Sounds very positive - congratulations!

[pdxindy]

I don't like the metadata stuff like in NI.

It is no easier for me than a simple preset menu. I would not remember what categories I used for a particular preset I am looking for and all the filtering options make me spend more time.

I would like to keep the Zebra presets as they are but with some added facility like drag-n-drop.

[amoeba]

ya, D&D or a simple add to favs would be great.
really pleased to hear midi patch change is making the cut too! that will be really helpful for live work.

[Urs]

ya, D&D or a simple add to favs would be great.
really pleased to hear midi patch change is making the cut too! that will be really helpful for live work.

Yep!

Program Change *is* still full of problems, but I have a concept... there'll be a dedicated folder for Program Changes, i.e. like in the Wavestation, and my recent rewrite of system functions (related to receptor compatibility) have decreased patch loading time greatly. In fact, patches now load almost twice as fast. In a similar way, the editor window should open faster, too!

Cheers,

Urs

[musicall]

instead of add to favorites you can just create a favorites folder and save all your favs to that...thats what i do.

[Urs]

instead of add to favorites you can just create a favorites folder and save all your favs to that...thats what i do.

Yep.

I think I'll add something completely different. What about adding colours to patches. For instance a patch can either be red, yellow or green. No need to move them in folders, because for each colour you get a smart folder that shows all of that colour. It's up to the user to decide what each colour means for him...

#---

I've also made up my mind about preset descriptions.

Technically there are 3 different ways:

1. Description inside patch
2. Description in patch databse
3. Description in extra file per patch

Now, we have to consider that not every patch will have a description. I can't afford to hire a freelancer to work on just that for a year

We also have to consider that it might be useful to read/see the description before actually loading a patch.

Due to the fact that there are thousands of patches already that have no description at all, there must be a way to easily add them afterwards, i.e. from the different sources of the patches.

This lets me favour 3. - having an *optional* extra file per patch is great! This file can contain not only the description but also the colour code. It can be parsed way faster than a whole preset, thus it's ideal for having patch info *before* loading a file. There's no need to load/parse anything to indicate the existance of a description file... its existance can be verified during a simple directory scan.

So yeah... I think we're on a good way to meet anything improvement in the preset sector...

Later,

Urs

[tboulette]

Urs,

For what its worth, I like the color idea. Is it fairly simple to implement?

-Tim

[Urs]

For what its worth, I like the color idea. Is it fairly simple to implement?

Why yes

It should be pretty easy to do. As should the whole idea be... there are a lot of logistics involved, such as special buttons/behaviours in the gui, but I've pretty much worked it all out... just gotta code a couple of days...

But of course, the most important thing for now are a couple of fixes... that has to be done first...

Later,

Urs

[dln]

For instance a patch can either be red, yellow or green. No need to move them in folders, because for each colour you get a smart folder that shows all of that colour. It's up to the user to decide what each colour means for him...

Excellent idea! See, metadata can be awesome.

This lets me favour 3. - having an *optional* extra file per patch is great! This file can contain not only the description but also the colour code.

Absolutely. Also, this be a standard key/value pair format (yaml,xml,ini,whatever) so we can store author, copyright, license info and whatever - e.g extra metadata without having to add code.

This will make for some slick preset browsing on the web too.

[mkastrup]

How bout a patch defaults to show notes in the FX window like this:

http://www.michaelkastrup.com/synthdemos/z2_notes.jpg

EDIT: Changed the pic to one more obvious place.

/Michael

[bmrzycki]

Yay metadata!

One suggestion, how about smart folders for things like ARP or XY's used. There's been a couple of times I wanted to use an ARP sequence from one patch in another and later forgot which patch had the arp.

Maybe preset filters? I don't want to blow this out of proportion, but it'd be really cool to say list all FM presets that use the Arpeggiator.

Oh and +1 for Michael's notes!

One other (slightly offtopic) question directed at Urs; have you heard about Hermode tuning? I saw z3ta+ boasting it's the only syft synth to implement it. When I read about it at http://www.hermode.de/ it sounded interesting. I was wondering your take on it or if you had even heard about it at all.

[nl3]

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

...Just the MSEG bug is still at work. Bummer.

Urs

I could say that MSEG presets like "Organ 'R' Us" are cpu overloading on 60/70% times i recall it and crashes after 2 or 3 notes played, more if played on the low-to-center side of the keyboard.
When it's ok,it works full time.
[img=http://img249.imageshack.us/img249/2447 ... jp6.th.jpg]
[img=http://img249.imageshack.us/img249/4527 ... ny5.th.jpg]
PGi

[Urs]

Yo all, just a quicky because I'm supposed to go to bed...

All Emagic synths do Hermode tuning... they (Hermode guys) contacted me once but I didn't get what exactly they wanted. For now we'll stay with Scala/.tun files until any more exotic ideas become clear enough for me to understand...

Regarding the extra files... it'll probably be a text file, just like .h2p presets. I honestly don't like the xml-ish overhead of key-value-node-tree-attribute-sub-conscious-ness. I mean, we're not talking universal use here. We're talking use in a single engine...

Ooooph... Must! Sleep! Now!

[bmrzycki]

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

...Just the MSEG bug is still at work. Bummer.

Urs

I could say that MSEG presets like "Organ 'R' Us" are cpu overloading on 60/70% times i recall it and crashes after 2 or 3 notes played, more if played on the low-to-center side of the keyboard.
When it's ok,it works full time.
[img=http://img249.imageshack.us/img249/2447 ... jp6.th.jpg]
[img=http://img249.imageshack.us/img249/4527 ... ny5.th.jpg]
PGi

I belive that's the MSEG bug Urs is chasing down. I've heard Organs R' Us mentioned about it before. If you don't load this particular patch do you still see it?

[amoeba]

1. Description inside patch
2. Description in patch databse
3. Description in extra file per patch

i would pass on 2 for sure. of the remaining, i like 1 for portability (also why i don't like 2, and lean away from 3).

i will leave the heavy reasoning to the code master(s), but i really don't see much benefit for 3 over 2, since .h2p is a text file already (but i do understand cutting out the overhead of parsing the rest of the file). but either way i'd happy. i am just pleased that Urs is so transparent with his thoughts, and so open to user suggestions/feedback. i wish the whole world worked this way. thanks, Urs.

oh - the color labels w/ smart folders thing sounds really great! for me, favorites can easily be dealt with this way.