You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
(23) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(3) |
Feb
(4) |
Mar
(29) |
Apr
(13) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2004 |
Jan
(2) |
Feb
|
Mar
(10) |
Apr
(1) |
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
(7) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
(6) |
Nov
(4) |
Dec
(3) |
2008 |
Jan
(5) |
Feb
(17) |
Mar
(27) |
Apr
(16) |
May
(16) |
Jun
(8) |
Jul
(18) |
Aug
(14) |
Sep
(5) |
Oct
(11) |
Nov
(27) |
Dec
(26) |
2009 |
Jan
(25) |
Feb
(6) |
Mar
(14) |
Apr
(32) |
May
(84) |
Jun
(78) |
Jul
(31) |
Aug
(16) |
Sep
(21) |
Oct
(39) |
Nov
(7) |
Dec
(7) |
2010 |
Jan
|
Feb
|
Mar
(36) |
Apr
(58) |
May
(77) |
Jun
(56) |
Jul
(42) |
Aug
(45) |
Sep
(22) |
Oct
(7) |
Nov
(2) |
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: wires <wi...@xs...> - 2002-08-13 01:30:23
|
Hi, I'm am working on a project like gAlan myself and it is actually scary how much my projects looks like yours. Up to the design of the GUI components (with a lollipop like shape as IO port). We've also made the same technology choices: event driven, gtk, glib. :) These similarities to our projects are so striking that I think we should cooperate. I'm sorry that it got such a big story, but I wanted to tell you all at once. I'll give you and overview of the differences, hopefully this gives you and idea on what we could help eachother. 1. The main difference is that I focus on video and 3d mostly. I've always kept audio in mind, and the approach is similar, just different data types and clock sources. first I was thinking about adapting your plugin format, it's similar in function to mine, which i've adapted from LADSPA again. This requires no change in gAlan, and we both benefit from it. However, to use the same plugin format for video too, it will require some minimal changes (most likely backward compatible). I'll just try that and report you on the needed changes, after which you can decide if you are okey with that (and I'll help with conversion then ofcourse). 2. There is another (more important) difference. I've intended to create the system as a library for use in games, stand alone applications and demos. Therefore, I've seperated the GUI from the library. On top of the library I will build a "kernel" executable that exposes the API to a network socket. On the client side there is a wrapper API that connects to the kernel and makes the API calls there. Nothing spectacular. The kernel is comparable in functionality like gAlan, except for the GUI ofcourse. I've decided to put a "middleware" library inbetween the kernel and the gui. The idea is that if a complex feature can be implemented based on the kernel's functionality it will be and it is abstracted in the middleware library. I'm not sure if this is completely clear, so I'll give you an example. The sheets in gAlan can actually be unwrapped to a big patch, which is inconvenient for the user but doesn't matter for the processing algoritm. Therefor I do not provide sheets in the kernel API but implement them in the middleware. I'm quite sure you've taken a similar approach. Another item is a multicable (serveral connections/bindings that look like one big multicable on the GUI). There is more to it that this, because I intend to use more that one computer for video processing. the kernel/middleware seperation allows me to have *just* the calculations in the kernel, no housekeeping or stuff like what should be calculated on what computer. adding the middleware keeps this entirely transparent for user of the middleware API. Also, the middleware could give the end user different scopes, so that two different users can work on different patches on the same kernel without interfering each other. Etc, Etc... I believe gAlan would benefit from such an approach as well and I think that using this approach will allow us to share much code. 3. Another small difference is that the kernel doesn't know anything about GUIs, neither do the plugins. Apperantly the gAlan plugins have the ability to supply their own dialogs and controls. The GUI could ofcourse load a seperate GUI part of the plugin for that, and the kernel could ignore it. I have a lot of ideas on the GUI, but i've been coding the GUI in C++ (the middleware app is C++ to), and I would like to keep it that way. If you could help me seperate the main patch editing area from gAlan so that I (or others) could use it in my code, i'll help you develop the GUI furter: - multicable - allow user to move the i/o ports around the plugin - implement those glue-diamonds so you can 'bend links round corners' - undo/redo - create a nice sequence "widget" - whatever else needs to be done My software is mostly just test cases, beta versions, video DSP code` tests (windows/linux) and designs. I've started coding on the final version as described above three weeks back. I have not actually coded anything on the GUI, or middle ware yet, except from tests. The kernel code is minimal, but very thight and mem leak/compile warnings free. Please tell me what you think about all this. thanks and cheers, Jelle. -- http://defekt.nl/ |
From: Torben H. <to...@gm...> - 2002-03-05 14:38:55
|
I have submitted a patch for galan-0.2.2 which adds many plugins and the ability for galan to open multiple sheets and reuse a sheet as a component in another sheet. i hope that there are some poeple on this list as i need some suggestions on how the interface should be designed in the future. --- Torben Hohn --- to...@us... |