New development perspectives.

[matterblue]

I've got a version of Zynadd (mainly the additive synthesizer) packaged in a JUCE GUI already. The project is called Capsaicin and will be a new instrument... the code is a bit under testing but it works well as it is. At the moment i can only do a linux build, but since it is juce based, can live on its own, and can be compiled as standalone application (linux, mac, win), vst plugin (linux, mac, win), AU (mac), RTAS (win, mac) and if you plan to release a new plugin technology (Dx or Fruity or whatever)... well it's only a matter of writing a wrapper for it.

i will release it in the next days if i find some time for doing it. That project has being laying around on my hd for such a long time !!! And i need people that likes to help the jucetice project !

How?
I don't do not understand nothing *smile*

- It is based on Zyn code but does implement only a subset?
- It is platform independant but compiles only on Linux yet?
- It is not Zyn finally, because you plan to release it under a complete new name (and synth project as you say)?
- So I assume it will be open sourced too and distributed under GPL conditions.
- What is the 'jucetice' project?

btw: that GUI looks intuitive.

---

[matterblue]

nice work on that capascin project man. very hip to see juce in action taking on a big complex project.

just what are the limitations of the FLTK? i need to know what image formats are acceptable, and how controls are to be created, etc, ahead of time as much as possible to prevent redundant efforts later.

If I integrate VSTGUI into the existing code (so that FLTK is merely used for the standalones to provide a main window), then the specifications for VSTGUI apply. This means preferable PNG support and the typical snitched images for knobs and so on.

---

[grymmjack]

nice work on that capascin project man. very hip to see juce in action taking on a big complex project.

just what are the limitations of the FLTK? i need to know what image formats are acceptable, and how controls are to be created, etc, ahead of time as much as possible to prevent redundant efforts later.

If I integrate VSTGUI into the existing code (so that FLTK is merely used for the standalones to provide a main window), then the specifications for VSTGUI apply. This means preferable PNG support and the typical snitched images for knobs and so on.

---

cool. that's what i like to work with. so you can do RGBA 32bit pngs to be sure?

[djsubject]

- What is the 'jucetice' project?

AFAIR its a linux project to port open source win vst plugins to native linux vst from the little i know through being a XT2 user,


http://www.anticore.org/jucetice/?cat=16

its come a long way since i last tinkered with linux,

but alas it seems i will be staying a Microslave

although i do have Ubuntu Studio installed on my DAW as a 2'nd boot but i cant for the life of me work out how to upgrade the alsa to the one that supports the E-MU1820m

being dyslexic most things you cant do with mouse clicks confuse me

Subz

[djsubject]

cool. that's what i like to work with. so you can do RGBA 32bit pngs to be sure?

googled it & found this

If you now want to export your alphatransparent pictures with RealDraw, so you have to do that in (32bit!) PNG format. (That's the alphatransparent format, not 24 bit - which has no transparency!)

Then use the latest VSTGUI framework and import the resources as a new resource with the foldername "PNG" (this is a required convention).

Then set the USE_PNG_ (or equally named) flag and compile your plugin. Don't forget to include the PNG framework, which is NOT a part of the VST SDK and must be downloaded elsewhere and connected to your code.

here

http://www.kvraudio.com/forum/viewtopic.php?t=85235

so its lookin like it should work,

Subz

[grymmjack]

good looking out subz.

[krakengore]

- It is based on Zyn code but does implement only a subset?

It is based on the Zyn project, and i have put the Zyn synth code directly inside a juce plugin. So it is 100% juce compliant and it does not contain a single line of platform dependant code.

- It is platform independant but compiles only on Linux yet?

It is platform independent, but i'm living in gentoo linux actually, and i haven't already had the chance to make a visual studio/Xcode project yet (i have a mac and a virtual machine with windows but that's annoying stuff ).

- It is not Zyn finally, because you plan to release it under a complete new name (and synth project as you say)?

It is Zyn, but i like to divide this from the Zyn project itself since it is a subpart of it, taking only what i like most of the core synth.

- So I assume it will be open sourced too and distributed under GPL conditions.

Of course, it will be released with the source code.

- What is the 'jucetice' project?

It is my personal struggle to make the linux audio/plugin experience the most valuable experience ever, trying to bridge the gap between the "others" platform music scene and the linux one. It features a multi plugin host and some kind of gui plugins that try to be of high quality and in the same time attractive to the musician (and easy to use).

[krakengore]

nice work on that capascin project man. very hip to see juce in action taking on a big complex project.

just what are the limitations of the FLTK? i need to know what image formats are acceptable, and how controls are to be created, etc, ahead of time as much as possible to prevent redundant efforts later.

If I integrate VSTGUI into the existing code (so that FLTK is merely used for the standalones to provide a main window), then the specifications for VSTGUI apply. This means preferable PNG support and the typical snitched images for knobs and so on.

---

vst gui sucks. it is better that you check out how to make a plugin with juce, and stick with that. you can use PNG from there but you have the flexibility to make your plugin code technology agnostic, and then recompile it as VST, standalone or whatever.

that's my advice will make the life a lot easier for everyone !

[matterblue]

cool. that's what i like to work with. so you can do RGBA 32bit pngs to be sure?

Yes.

[matterblue]

vst gui sucks. it is better that you check out how to make a plugin with juce, and stick with that. you can use PNG from there but you have the flexibility to make your plugin code technology agnostic, and then recompile it as VST, standalone or whatever.

that's my advice will make the life a lot easier for everyone !

Well. That meight be true. But:
I know VSTGUI already (have alot of experience with it - can code and subclass it while sleeping *smile*).
If I start with JUCE, then I fear I have to learn alot new stuff. Tht's actually time consuming and will delay the project finalization.

There is virtually no difference in portability of VSTGUI and JUCE. Both are platform independant. But as far I've seen. VSTGUI has some advantages over JUCE. Especially regarding the reuse (sharing) of resources.

Unfortunately many similar widget frameworks have a problem with this, obviously: If you have multiple instances of a graphic intensive widget (a 128 frames stiched image for a knob for instance), the most other frameworks copy them multiple times into memory. That's inefficient and very odd. I do not know yet, how JUCE is solving the problem...

For such a big synth like Zyn, multiplying the resources in memory would be a disaster of wasting memory and also affect the performance finally, btw.

---

[matterblue]

An idea (big STOP):

If the 'krakengore' project implements Zyn already...
WHY NOT USE IT AS A BASE FOR FURTHER DEVELOPMENT?

I fear the invention of the wheel for the THIRD time here with forking the codebase again...

???

And krakengore: Porting is no problem! I have Windows XP, Vista, SUSE Linux 10.3 and Max OS X Leopard running on my machines. That's absolutely neccessary for doing xplatform development.

But an absolute requirement is then to put the project into a SVN repository, because all build systems will synchronize the code this way.

---

[krakengore]

Well. That meight be true. But:
I know VSTGUI already (have alot of experience with it - can code and subclass it while sleeping *smile*).
If I start with JUCE, then I fear I have to learn alot new stuff. Tht's actually time consuming and will delay the project finalization.

There is virtually no difference in portability of VSTGUI and JUCE. Both are platform independant. But as far I've seen. VSTGUI has some advantages over JUCE. Especially regarding the reuse (sharing) of resources.

Unfortunately many similar widget frameworks have a problem with this, obviously: If you have multiple instances of a graphic intensive widget (a 128 frames stiched image for a knob for instance), the most other frameworks copy them multiple times into memory. That's inefficient and very odd. I do not know yet, how JUCE is solving the problem...

For such a big synth like Zyn, multiplying the resources in memory would be a disaster of wasting memory and also affect the performance finally, btw.

---

yeah go for it ! Anyway juce have an extremely cute resource management. you can decide at runtime if you need a shared resource or a duplicated version of it (think the case of a shared image and a plugin specific copy of a changeable fxb file). it's up to you
anyway we will end up having 2 different synths... duplicating a lot of efforts !

ps. most of my interfaces code is done with the jucer so it is very simply to rearrange widgets in the plugin itself without touch the code at all.

[matterblue]

Uuups.
I added something to my last post. Please read it.

---

[krakengore]

ok i understand the point. i will first release it so you can give a chance to look at the code and try to compile it under another platform (should be straightforward if you have a settled up development platform with all libraries and such).

then we can make a svn repository for it.

[matterblue]

Yep! That's the way it goes.
PM me, if the project is released.

---