Hi Loki, 2011/1/6 Loki Davison <loki.davison(a)gmail.com>om>: Actually that is my problem, my terrain till now was more in Webdevelopment - CMS-CRM, custom modules I did Java and Python, mainly object oriented. Most synth apps I see in Linux are coded in C, at least the engine, and stuff like pointers really don't fit into my brain .. might be my age ... I will have a look at that ... regards, Sascha

Hi! On Fri, Jan 7, 2011 at 2:01 PM, Robin Gareus <robin(a)gareus.org> wrote: Thanks for the pointer to that! :-D Short concise very informative.. downloaded for future reference! There wouldn't happen to be something similar you know of for threads / Glib threading by chance? -Harry

2011/1/6 Loki Davison <loki.davison(a)gmail.com>om>: By the way, to advance my skills C++ and DSSI/LV2 .. is anyone willing to offer a mentorship?? regards, Sascha

2011/1/6 Jeremy <jeremybubs(a)gmail.com>om>: Oh thanks .. Thats all they have for the Tyrell, the planing of this synth and what it should do is described as a sort of manual in one of the links http://www.amazona.de/index.php?page=26&file=2&article_id=3191&… here from page 2 the moogulator describes in detail what the synth does. Sorry, all in german. Urs Heckmann a german VSTi developer took some of the code of his existing VSTi's and made the alpha plugin within 3 days. This U-He plugin will be free- or magware but will stay closed source. Therefor my idea after the post of Malte Steiner here was to take the engine of his "minicomputer" from http://minicomputer.sourceforge.net/ Malte himself had the idea of making this synth polyphon and monotimbral as LV2 or DSSI plugin, but lacks time. Advantage of this synth is that it is an absolutely lightweight. regards, saschas

Okay, looking at the sources a little more, it seems like all we need to port is the minicomputerCPU component. The editor can just be used to communicate to the plugin using the lv2ExternalUI extension. Jeremy On Thu, Jan 6, 2011 at 4:32 AM, Jeremy <jeremybubs(a)gmail.com> wrote:

On Thu, Jan 6, 2011 at 5:31 AM, Sascha Schneider <ungleichklang(a)gmail.com>wrote;wrote: So wait, I'm a little confused by this. Are you saying that the engine is composed of 8 copies of the same synth, each being monophonic, but allowing you to do polyphony if you redirect the notes to different channels each (so each monophonic synth plays a different note)? If you want to make something like that polyphonic that would be very easy. You'd just set up a queue of open synth engines. You could even set the polyphony by an option that you could adjust (at the expense of memory). So if you're worried about that, don't be worried. Since it is a Jack app, it's already largely in the format we need, you just need to add some metadata, and switch around the way it handles MIDI and OSC (well, that's the time-consuming part). As for the GUI, I think since it uses OSC, you could just add some metadata and it would work as a LV2ExternalUI (well, very minor source code modifications would be necessary). However, if you're interested in designing a new GUI, that would be possible too. Jeremy

On Thu, Jan 6, 2011 at 6:21 AM, Sascha Schneider <ungleichklang(a)gmail.com>wrote;wrote: your voices. This doesn't really make sense if you are automatically assigning the notes to synth engines. I think perhaps the best way would be to have one set of settings for *all* copies of the synth engine, and if you want different settings, then you'd have to create another copy of the plugin. so there are somewhere in that code 8 midiports that route the Yup, and I'm saying we can just build in that functionality into the plugin.

Hi Malte, So I've been working on converting it some more. If you could give me some pointers as to the meaning of variables, that would be useful. What are the EG... variables, like "EG", "EGFaktor","EGtrigger", and "EGState"? Also if you're looking for a channel stealing algorithm, try this: the type of a synth engine is "synth" typedef struct _synthblock { _synthblock* next; _synthblock* previous; synth item; } synthblock; Initially, you start out using the synthblock as an element of a singly linked list of free synths. You only need to use the "next", pointer, and can ignore the "previous" pointer. You can either only keep track of the head, and use it as a stack, or you can keep track of the head and the tail and use it as a queue. Either way, adding is a constant time operation, and taking the most recently or least recently used one is also a constant time operation. Then, you have an array which keeps track of which notes are on. synthblock* currentnotes[NUM_MIDINOTES]; When you get a note-on signal, you pop the first synth block off of the "free synth" list, and then you add a pointer to it in this array, indexed according to what note it is playing. However, you also add it to the * doubly* linked list of which synths are playing, again, a constant time operation, because you are just twiddling with the next and previous pointers of two blocks. Now, the array contains a pointer to a block which is in the doubly linked list. Now, when you want all the synths to process, you can iterate through the doubly linked list, and thus you only need to process the ones that are playing notes. When you receive a note off signal, you look up the note in the array, and then remove that item from the doubly linked list, and add it to the singly linked one. In the end, you can do everything in constant time (or O(number of notes being played)) Anyway, I don't know if it's pointless for me to put my ideas here, but I'll probably implement it too, if this doesn't make sense now. Jeremy On Thu, Jan 6, 2011 at 3:36 PM, Malte Steiner <steiner(a)block4.com> wrote:

Yeah, that would probably be a good idea. I'm pretty bad with designing and implementing GUIs. Jeremy On Fri, Jan 7, 2011 at 3:37 AM, Sascha Schneider <ungleichklang(a)gmail.com>wrote;wrote:

Hi back, o.k. I spend a little time reading and experimenting with UI-Toolkits (please keep in mind that my app-programmingskills are limited) and have the following thoughts: - for the UI we will mainly need sliders and knobs - the UI should be lightweight to run several plugins per song/track - as far as I have seen only 2 UI-toolkits have knob-widgets include in the standard lib and that are FLTK and Qt - gtkmm has no knobs but with gtk and cairo I can draw some -> brummer, the dev of guitarix gave his o.k. to use his knobs and sliders regarding my programming skils: - FLTK is ... less documented (to be polite) .... development unsure - Qt is big, unless we say that most people use QJackCtl, then Qt support is installed anyway - gtkmm sits on top of gtk and the most designfiles are kinda "closed source" .o I think my first step will be to redesign the FLTK-UI and make it more Zynaddish / Yoshish keeping the nice PPG colors Work began yesterday - be polite - this is my first UI ... I will add a "soundchooser" like in zynadd so that we can create banks and a "midi-map" window. regards, saschas

2011/1/8 Harry Van Haaren <harryhaaren(a)gmail.com>om>: I know that, I meant the object files with the ending .o Saschas

On Sat, Jan 8, 2011 at 10:46 AM, Sascha Schneider <ungleichklang(a)gmail.com> wrote: this is not correct either. you can do GUI design work either using a RAD tool like Glade OR by implementing the design directly in a normal programming language. In the first case, you get a glade file that is loaded by the program and defines the design. in the second case, you compile and get object files that are linked into the program itself. its even possible (and even common) to do a bit of both - part of the program's design might be done with Glade and part of it in C++ with gtkmm (for example). the same is true for almost all other GUI toolkits that have RAD tools - its true for Qt, for Cocoa, etc etc etc

WAS: Re: [LAD] Devs needed for opensource virtual analog softsynth idea .............. I wouldn't mind jumping in and work a little on a key assign/voice stealing algorithm. Since I happen to need a better one myself for another project, it would be nice if it is kept separate from the private working set of the voice ( - the "state" or what a voice needs to know about itself to render the next sample.) This would be the preferred case anyway for efficient code generation for an arbitrary, irregular polysynth architcture. Suggesting the following outline for data structures: // Voice state // ----------- // We want to be able to autovectorize as well as CUDA'fy. Data // elements must therefore be arranged as "structs of arrays" // rather than "arrays of structs," so that operations on // neighbouring data will be identical while also keeping memory // access' in straightforward wide chunks ... #define VOICES 16 // less than 16 will not (automatically) play well // with SSE, because of instruction latency typedefine struct { int phase[VOICES]; // current position int freq [VOICES]; // value to be iteratively added to phase } Oscillator; typedefine struct { } Envelope; ... ... typedefine struct { Oscillator osc[2]; // 2 oscillators on each voice Oscillator lfo; Envelope env[2] ... } VoiceState; // ... which all means that there is no pointer to a voice! There is // an index though. All array elements sharing the same index also // belongs to the same voice. Assuming we do not need more voices // than a hundred and then some, a byte will be plenty for the index: typedefine struct { unsigned char next, previous; } VoiceList; // Depending on where in its lifecycle a voice is, it can be more // or less desireable to "steal" it. At first we will of course look // for one that is idle and not in use at the moment, second best is // one in its final fading release stage. For each stage, we will // maintain a FIFO, changing whenever a key (or pedal) is struck // or released. Worst case is stealing a voice the user is still // holding his hands on. For a monotimbral synthesizer: typedefine struct { // index to first VoiceList element for each que, or 0xFF if empty unsigned char idle, release, sustain, sostenuto, keyon; VoiceList voice_list[VOICES]; } VoiceAssign; /J On Sat, 2011-01-08 at 05:07 -0500, Jeremy wrote:

Hi, The default is silent, have you installed the preset sounds and load a multi and / or a preset sound? That should get you started Please consult the minicomputerManual PDF which should clearify all the questions. Midi to the minicomputer alsa port is only for programchanges while to the minicomputerCPU is for midi notes on channel 1 to 8. OSC goes from the gui to the engine for changing the parameters, the OSC messages are explained in the manual. Cheers, Malte

can you send me a screenshot of the editor? maybe its something which is obvious to me. Is this the original Minicomputer or some changed version? Cheers, Malte -- ---- media art + development http://www.block4.com new on iTunes: Notstandskomitee Automatenmusik http://itunes.apple.com/us/album/automatenmusik/id383400418

Hi, from the screenshot I see that you need to crank up the volume, its on the right side. Either the mix vol for the mix output and/or the id vol (individual volume) for the direct voice out and/or the aux channels volumes. Or you could try to load a multi which should have that settings. I know a synthesizer should rock out of the box but I played safe with Minicomputer which causes quite some confusion. The dedaults could be better, something for the todo list. Cheers, Malte On 16.02.2011 03:36, Jeremy wrote: -- ---- media art + development http://www.block4.com new on iTunes: Notstandskomitee Automatenmusik http://itunes.apple.com/us/album/automatenmusik/id383400418

On 06/01/11 10:31, Sascha Schneider wrote: Voice management isn't that easy to get right, especially if you want to support things like Sustain and Sostenuto (hold pedals) and voice stealing correctly. It took me ages to iron out the known polyphony bugs in Calf Organ. K.

On Thu, 2011-01-06 at 09:09 +0100, Sascha Schneider wrote: You don't really need a "mentor", you just need a tutorial on C programming and to sit down and do it. Once you've got your head around things a bit, grab a copy of xsynth-dssi and start poking around inside. It's a great example of a practical DSSI synth plugin. Gordon MM0YEQ