Menu
▾
▴
radiator-devel — Mailing-List related to the development of relator.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(47) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|
|
From: <nik...@t-...> - 2002-09-07 18:51:35
|
hello, as i said very often in the chat , i have problems with the libraries i were using for my gui. i am still using ogl a part of the wxwindows kit. it seemed to satisfy the needs i had, after looking around for gnome/paragui stuff. the problem is that i end up debugging when i wanted to step further the functionality that the given example-apps offered. the problem is not my lazyness which caused the earlier softwaredevelopent to fail, it was the lacking documentation. not even 25% of the library is documented in the reference offered, also the reference points to topics and library functions which aren`t documented at all. after going throught he library sources it came out that nearly everything i needed to make for example more complex shapes was either not implemented, or failing because of errors/bugs(?) still unknown to me. i will use doxygen to make an auto-generated documentation of it. if i still wont succeed in the next days i will abandon OGL, maybe wxwindws completely. at this very moment i feel tired, disappointed at me and pissed about the libraries. i dont know if i should really help you guys , still. with kindest regards, niklas |
|
From: Tim R. <ti...@ga...> - 2002-08-28 10:34:04
|
On Wed, 28 Aug 2002 04:47:21 -0400 Patrick Mahoney <bo...@in...> wrote: | How about adding an 'include' instruction in the script files and | support for constants? This way, every environment configuration could | include a common file defining the major all the constants (ex: define | PARAM_SAMPLING_RATE 0, etc...) It would be easy to add include file support. What would be even easier would be to run script files through cpp, the C preprocessor, which gives you #include, #define and macros. I've tried the same tokenizer on a different project with preprocessed files and it can cope with the output from cpp. -- Tim Robinson <ti...@ga...> |
|
From: Patrick M. <bo...@in...> - 2002-08-28 08:47:24
|
How about adding an 'include' instruction in the script files and support for constants? This way, every environment configuration could include a common file defining the major all the constants (ex: define PARAM_SAMPLING_RATE 0, etc...) Pat Mahoney, no 22 |
|
From: Tim R. <ti...@ga...> - 2002-08-26 16:28:24
|
On Mon, 26 Aug 2002 14:07:22 +0100 Tim Robinson <ti...@ga...> wrote: | | > -- Broke ReaderStereo. OK, I didn't break it, I just haven't converted | | > it yet. I'll do that next. | | | | Hmmm... Looks redundant... How about having only 1 reader module with | | 2 outputs... If its mono, both outputs are the same. Waddaya think? | | OK, good idea. That's also the correct behaviour for playing a mono | sound file through a stereo setup (imagine if somebody wired together | two sets of 'circuitry' but only played mono through it). It makes the | code easier, too. I've just done that and it seems to work OK. I've also added partial sample rate conversion support: Reader will automatically compress/expand samples to a power of two multiple of the final sample rate. That is, assuming the output is going to be 22050 Hz, Reader can play files at 11025 Hz or 44100 Hz (88200 Hz, etc.). However, if the file's sample rate isn't one of these (e.g. 12345 Hz), it will sound crappy (Reader converts the sample rate to the nearest power of two multiple, so 12345 Hz becomes 22050 Hz). -- Tim Robinson <ti...@ga...> |
|
From: Tim R. <ti...@ga...> - 2002-08-26 13:19:51
|
On Sun, 25 Aug 2002 23:19:14 -0400 Patrick Mahoney <bo...@in...> wrote: | > -- Broke ReaderStereo. OK, I didn't break it, I just haven't converted | > it yet. I'll do that next. | | Hmmm... Looks redundant... How about having only 1 reader module with | 2 outputs... If its mono, both outputs are the same. Waddaya think? OK, good idea. That's also the correct behaviour for playing a mono sound file through a stereo setup (imagine if somebody wired together two sets of 'circuitry' but only played mono through it). It makes the code easier, too. -- Tim Robinson <ti...@ga...> |
|
From: Patrick M. <bo...@in...> - 2002-08-26 03:43:48
|
> i talked to tim yesterday and just wanted to make clear that the gui is > _my_ part, i know i am developing quite slowly but i want to learn > c++/c > :) It was _I_ who suggested to Tim to for him to take over the gui stuff. Making a complete gui is a very complex task. It is not a matter of drawing rectangles and moving them around. It's a set of concepts of data related to views and views related to data and managing updates between the two relations. I therefore do NOT believe it's appropriate for a person learning c++ to start things off by writing a gui. Some of the most complex design patterns are of use specifically (or only) within a gui environment. The GUI is what our whole project will be judged upon by our pairs. In other words, if the gui stinks, the whole project stinks. As of now, the quality of the gui doesn't matter. But as soon as we will want our project to become 'public', we will need a very efficient gui. At that time, if lynx's gui hasnt reached that level, i believe another gui will have to be developped in parallel. There's no such thing as some part being one's own. We're all in this together. In summary, we're ALL in this to learn, myself included. But one's learning shall NOT be the source of delay of the whole project. Pat Mahoney, no 22 |
|
From: Patrick M. <bo...@in...> - 2002-08-26 03:19:21
|
> -- Broke ReaderStereo. OK, I didn't break it, I just haven't converted > it yet. I'll do that next. Hmmm... Looks redundant... How about having only 1 reader module with 2 outputs... If its mono, both outputs are the same. Waddaya think? Pat Mahoney, no 22 |
|
From: Tim R. <ti...@ga...> - 2002-08-25 14:09:13
|
Hi all, A couple of new updates: -- Switched from char/short/whatever in buffers to float. Each sample is a float; buffers have BUFFER_SIZE elements and are sizeof(float)*BUFFER_SIZE in size. This avoids having each module know about sample formats etc. -- Wrote a Windows Wavout module. I now have wavout-win32.cpp and wavout-win32.h, because the WavoutWin32 class needed a lot more private data members than the Unix equivalent. -- Converted Reader and Writer (and all the other modules) to use floats. Reader now looks at the bits per sample value in the wave header and converts intelligently. Writer just dumps raw 16bps shorts to disk, without a .wav header or anything (Cooledit on my machine will read and successfully play such raw output files). It shouldn't be hard to put the proper .wav format support into writer though. -- Broke ReaderStereo. OK, I didn't break it, I just haven't converted it yet. I'll do that next. -- Tim Robinson <ti...@ga...> |
|
From: <nik...@t-...> - 2002-08-25 13:18:42
|
-------- Original Message -------- Subject: wxWin Date: Sat, 24 Aug 2002 19:08:25 +0200 From: Niklas Klügel <nik...@t-...> To: Tim Robinson <ti...@ga...> References: <20020825052852.GA1088@thebrain> <200...@ga...> hi, i wanted to code today... add some stuff to the gui , but the problem is that i am having stupid errors/problems installing wx for gtk or motif on this machine. i KNOW it should work on IRIX, maybe someone of you two can help m elater on irc. i talked to tim yesterday and just wanted to make clear that the gui is _my_ part, i know i am developing quite slowly but i want to learn c++/c :) I did that back in the unununium days with asm and it worked well, yeah dave teached me alot i owe him much. thanks in advance, heh have a nice day... with kindest regards, niklas |
|
From: Tim R. <ti...@ga...> - 2002-08-25 12:48:26
|
On Sun, 25 Aug 2002 01:28:52 -0400 Patrick Mahoney <bo...@in...> wrote: | > BTW, forgot to ask: what is this practice of passing "const int&" as | > parameters to functions instead of "int"? | > | | It avoids making a copy of the parameter (&) while still making sure | that the original data will not be modified (const). I can see the rationale for passing "const a_very_big_struct&", but on most machines (i.e. all the ones we're dealing with), sizeof(int) == sizeof(int&), so the end result is that the compiler passes a pointer to the variable onto the stack and the function indirects unnecessarily through a pointer. In these situations, I ask myself whether the overhead of repeatedly addressing through a pointer (or reference) inside the function is more than the overhead of pushing the variable onto the stack -- here an int& costs the same to push as an int. -- Tim Robinson <ti...@ga...> |
|
From: Patrick M. <bo...@in...> - 2002-08-25 05:28:59
|
On Sun, Aug 25, 2002 at 01:25:33AM +0100, Tim Robinson wrote: > BTW, forgot to ask: what is this practice of passing "const int&" as > parameters to functions instead of "int"? > It avoids making a copy of the parameter (&) while still making sure that the original data will not be modified (const). PM, 22 |
|
From: Tim R. <ti...@ga...> - 2002-08-25 00:37:27
|
BTW, forgot to ask: what is this practice of passing "const int&" as parameters to functions instead of "int"? -- Tim Robinson <ti...@ga...> |
|
From: Tim R. <ti...@ga...> - 2002-08-24 23:34:22
|
On Sat, 24 Aug 2002 16:15:53 -0400 Patrick Mahoney <bo...@in...> wrote: | Module* (Environment::*)(anything) is a big no-no... There should be | no object, reference or pointer to a module or a link outside the | Environment class. The non-virtual Module::add_output_port and | Module::add_input_port serve that purpose. Every port has its index | and its name stored in the Module object. We simply need to add | Module::get_outputport_name(index) and | Module::get_inputport_name(index). OK, no problem. So how would we do that? str =3D env.get_outputport_name(moduleid, index); =2E..or: str =3D env.get_module(moduleid).get_outputport_name(index); | Sure, it also avoid the plugins which dont need std to be linked with | it. But what are the "void* param" (1st of register_plugin) and | "void*" (1st of add_module) for? That's a reference for the callback that Environment provides. Because you can have more than one environment class per process (e.g. multiple documents open), the static function that Environment passes as a parameter to register_plugin needs some way of identifying which module list it's adding to. In the sources I committed, I made this a pointer to the map of new modules, although it could point directly to the new modules list. | > -- Got src/plugins to link to bin/basic.rap instead of lots of .so. Thi= s | > resulted in a huge saving of disk space (with gcc each .so was taking u= p | > 700KB on disk with symbols included). This also avoids the need for me | > to maintain one VC++ project per module (VC++ only allows one target pe= r | > project). |=20 | What? Link with bin/basic.rap? Whats a .rap file? ?? It's the name for Radiator Plugin DLLs that lynx and I came up with this afternoon. :) It's a renamed .so or .dll file. | > -- Changed .shared rule to .shared.o. This lets us use .d files for | > sources that will always compile to .shared.o (the include $(OBJS:.o=3D.= d) | > doesn't know about .shared but it does know about .shared.o). |=20 | Wouldnt .pic.so be more representative? OK, sounds better. As I understand it, C++ code needs to be compiled differently when linking with PIC ELF in mind rather than static ELF, so =2Epic.o files are those that have been compiled with the -fpic compiler switch. | > -- Put POSIX-specific dlXXX functionality into environment_linux.cpp. | > The linux part of the string should be set to whatever $(PLATFORM) is | > set to in make.conf. |=20 | Hmmm... Wouldnt using the pthread-win32 lib avoid doing that? And if | we get further into multithreading, well need it anyway... Well, until we get into more complex threading scenarios (such as synchronisation), a couple of #ifdef lines is enough to provide portability between Win32 and pthreads. At least, putting in a bit of conditional code was more preferable for getting the stuff to run than tracking down and setting up pthread-win32. I guess using a proper portable thread library will be inevitable eventually, though. --=20 Tim Robinson <ti...@ga...> |
|
From: Patrick M. <bo...@in...> - 2002-08-24 20:15:57
|
> No real need. I just added a #ifdef in the CLI to get it to use > _beginthread on VC++ instead of pthreads. It doesn't seem to use libdl > or curses, either. see last paragraph. > > I've just started porting my testbed app to the new architecture. > However, I've come up against a fundamental obstacle: Environment > doesn't allow access to the names of modules' ports (this will be a > problem for the GUI too, clearly). I think the solution would be to add, > say, Module* Environment::get_module(int id), but I'll leave it until > I'm sure that you (Pat) can still compile with the changes I've made to > the codebase. Module* (Environment::*)(anything) is a big no-no... There should be no object, reference or pointer to a module or a link outside the Environment class. The non-virtual Module::add_output_port and Module::add_input_port serve that purpose. Every port has its index and its name stored in the Module object. We simply need to add Module::get_outputport_name(index) and Module::get_inputport_name(index). > > The major points: > -- Changed register_plugin to: > > extern "C" void register_plugin( void *param, > void (*add_module) (void *, const char *, CREATOR_FUNC)) > > Using a function instead of std::map avoids big problems on Windows. I > didn't get to the root cause, but I think it relates to the problem of > using new and delete across DLL boundaries: the DLL (basic.rap) uses one > heap, the EXE (cli.exe) uses another. When one tries to free the other's > memory you get a crash. I think that std::map was trying to do something > similar and it broke. In any case, calling the function avoids mixing > C++ standard library implementations (what if you wrote plugins in > Cygwin and the EXE in VC++? their template implementations are > different). Sure, it also avoid the plugins which dont need std to be linked with it. But what are the "void* param" (1st of register_plugin) and "void*" (1st of add_module) for? > > -- Got src/plugins to link to bin/basic.rap instead of lots of .so. This > resulted in a huge saving of disk space (with gcc each .so was taking up > 700KB on disk with symbols included). This also avoids the need for me > to maintain one VC++ project per module (VC++ only allows one target per > project). > What? Link with bin/basic.rap? Whats a .rap file? ?? > -- Changed .shared rule to .shared.o. This lets us use .d files for > sources that will always compile to .shared.o (the include $(OBJS:.o=.d) > doesn't know about .shared but it does know about .shared.o). Wouldnt .pic.so be more representative? > > -- Put POSIX-specific dlXXX functionality into environment_linux.cpp. > The linux part of the string should be set to whatever $(PLATFORM) is > set to in make.conf. Hmmm... Wouldnt using the pthread-win32 lib avoid doing that? And if we get further into multithreading, well need it anyway... Pat Mahoney, no 22 |
|
From: Tim R. <ti...@ga...> - 2002-08-24 17:59:50
|
On Sat, 24 Aug 2002 05:15:58 -0400 Patrick Mahoney <bo...@in...> wrote: | Tim: did you port the cli to windows? | I just read that the pthread library has been ported to windows as an | open source project with the lgpl license... | http://sources.redhat.com/pthreads-win32/ | | Might be as simple as downloading the .dll/.h files, setting you vc++ | environment, and recompiling... No real need. I just added a #ifdef in the CLI to get it to use _beginthread on VC++ instead of pthreads. It doesn't seem to use libdl or curses, either. I've just started porting my testbed app to the new architecture. However, I've come up against a fundamental obstacle: Environment doesn't allow access to the names of modules' ports (this will be a problem for the GUI too, clearly). I think the solution would be to add, say, Module* Environment::get_module(int id), but I'll leave it until I'm sure that you (Pat) can still compile with the changes I've made to the codebase. The major points: -- Changed register_plugin to: extern "C" void register_plugin( void *param, void (*add_module) (void *, const char *, CREATOR_FUNC)) Using a function instead of std::map avoids big problems on Windows. I didn't get to the root cause, but I think it relates to the problem of using new and delete across DLL boundaries: the DLL (basic.rap) uses one heap, the EXE (cli.exe) uses another. When one tries to free the other's memory you get a crash. I think that std::map was trying to do something similar and it broke. In any case, calling the function avoids mixing C++ standard library implementations (what if you wrote plugins in Cygwin and the EXE in VC++? their template implementations are different). -- Got src/plugins to link to bin/basic.rap instead of lots of .so. This resulted in a huge saving of disk space (with gcc each .so was taking up 700KB on disk with symbols included). This also avoids the need for me to maintain one VC++ project per module (VC++ only allows one target per project). -- Changed .shared rule to .shared.o. This lets us use .d files for sources that will always compile to .shared.o (the include $(OBJS:.o=.d) doesn't know about .shared but it does know about .shared.o). -- Put POSIX-specific dlXXX functionality into environment_linux.cpp. The linux part of the string should be set to whatever $(PLATFORM) is set to in make.conf. -- Tim Robinson <ti...@ga...> |
|
From: Patrick M. <bo...@in...> - 2002-08-24 09:16:03
|
Tim: did you port the cli to windows? I just read that the pthread library has been ported to windows as an open source project with the lgpl license... http://sources.redhat.com/pthreads-win32/ Might be as simple as downloading the .dll/.h files, setting you vc++ environment, and recompiling... Pat Mahoney, no 22 |
|
From: Tim R. <ti...@ga...> - 2002-08-21 10:14:01
|
On Wed, 21 Aug 2002 03:28:29 -0400 Patrick Mahoney <bo...@in...> wrote: [...] | It was only several hours later that I realized that... g++'s and | vc++'s floats are 32 bits-long (!). As of now, all of the modules have | been designed to use 16 bits signed integers... Neither compiler | implement 16 bits floating point data. So... Do we keep the 16 bits | integers (signed short) datatype? Any better idea? I suggest we move over to 32-bit real (or the C float data type, whatever that entails) -- the increase in size will be made up for in the efficiency of the code, since using floats will be better for the FPU. Using, say, fixed-point numbers will necessitate converting to and =66rom floating point for modules that do work in floating point (like the aforementioned sin, cos routines); normal arithmetic on fixed-point numbers will use the ALU and will likely be as fast as arithmetic on floating-point numbers in the FPU. | I found a freely available complete DSP book online written for | scientific-backgrounded students or professionals. Having read 3 | chapters tonight only, i can say that it looks _very_ well done... | www.dspguide.com This looks excellent! I immediately noticed equation 14-1, which relates to what Pat and I were confused about on IRC the other day. | Hows the GUI coming along? Are both of you guys working on it or is it | only lynx? Only lynx -- he hasn't showed anybody any code yet. --=20 Tim Robinson <ti...@ga...> |
|
From: Patrick M. <bo...@in...> - 2002-08-21 08:46:14
|
Hello Radiators, One thing i forgot to mention in the mail i sent yesterday... Tim and I agreed on specifying the one and only data format flowing through the modules... Yesterday, Tim suggested using floating point (see irc log for more info), keeping the sound data withing the [0,1] range. The interesting aspect of this technique was to avoid scaling each data when using the math library functions (sin, cos, ...). It was only several hours later that I realized that... g++'s and vc++'s floats are 32 bits-long (!). As of now, all of the modules have been designed to use 16 bits signed integers... Neither compiler implement 16 bits floating point data. So... Do we keep the 16 bits integers (signed short) datatype? Any better idea? I found a freely available complete DSP book online written for scientific-backgrounded students or professionals. Having read 3 chapters tonight only, i can say that it looks _very_ well done... www.dspguide.com Hows the GUI coming along? Are both of you guys working on it or is it only lynx? Pat Mahoney, no 22 |
|
From: Patrick M. <bo...@in...> - 2002-08-20 11:55:33
|
- out irs channel is logged 24/7. logs can be retrieved from: http://lesboys.ddts.net:8080/~radiator/ - new plugin/modules registration method is implemented. its the gui responsability to keep the modules<->plugins associations. - A couple of new plugins... - readerstereo: can play stereo wav files. 2 outputs: left & right. - mixer: in: A,B out: A+B , A-B - zero: out: zeros! :) I tried several combinations and put them in .rad scripts available in the /bin directory. Take care, Pat Mahoney, no 22 |
|
From: Tim R. <ti...@ga...> - 2002-08-19 13:08:31
|
On Mon, 19 Aug 2002 08:45:43 -0400
Patrick Mahoney <bo...@in...> wrote:
| > The Win32 PluginInfo constructor (where the calls to LoadLibrary and
| > GetProcAddress are located) will try to find the plugin_enum function.
| > If it does, it calls it to find what modules are supported; if not, it
| > assumes the plugin supports one module with the same base name as the
| > DLL.
|
| This is WAY too complicated... It doesnt have to be! Why dont we let
| the dynamic libs register the plugins they can create? Something
| like...
|
| extern "C"{
| void init(){
| extern map< string, Module*(*)() > creators;
| creators["reader"]=create_reader;
| creators["writer"]=create_writer;
| creators["wavout"]=create_wavout;
| }
| }
|
| Would it be simpler?
Part of the rationale of keeping track of which plugins are loaded and
export a given module is to allow the environment to maintain per-plugin
information.
For example, it's useful to be able to load and unload plugin .so's at
run time (e.g. if you're developing a plugin, you'll want the UI to
unload it so that you can recompile it). So the environment needs to
keep track of what plugins are loaded, and how and when to unload them.
Another thing: we may want to expand beyond the create()/plugin_enum()
(better to rename create() to plugin_create() for consistency?) to, say,
having .so's give the environment Plugin objects. Maintaining per-plugin
information gives us more flexibility.
| > | Another point... Each plugin is statically linked with the
| > | environment.lib library. Would it be worth it to make all the plugins
| > | share one instance of this library?
| >
| > Yes, it probably would. Options are:
| > 1) Turn the environment into a DLL and have the plugins and UI reference
| > it
| > 2) Export the environment functionality from the UI
| >
| > I think (2) sounds best. On Windows the plugin DLL can import from, say,
| > radiator.exe; I'm not sure of the Posix situation but I think it's
| > simpler there.
|
| Hmmm... I dont understand what would mean in option 2)... Could you
| explain?
Plugins could either (1) call Environment:: member functions in a shared
DLL, or they could (2) call the implementation in the UI executable.
--
Tim Robinson <ti...@ga...>
|
|
From: Patrick M. <pat...@po...> - 2002-08-19 12:50:19
|
We've got a functional threaded command line interface! Commands can also be written in a file which can be loaded by the cli. To make this all portable, we could use libboost. This would require to link everything with stlport implementation of stl... http://www.boost.org/ Waddaya think? Pat Mahoney, no 22 |
|
From: Patrick M. <bo...@in...> - 2002-08-19 12:45:49
|
> OK, what I've got so far:
>
> -- Environment maintains a list of PluginInfo classes, each of which
> represents one plugin
> -- PluginInfo knows how to load a plugin and ask it what modules it
> supports (it should also know how to unload it when the time comes)
> -- Environment::create can walk the list of PluginInfo's, asking each
> one if it supports the given module. If it does, it calls through the
> create pointer that PluginInfo saved
> -- If no PluginInfo claims to know about the module, the environment
> creates a new PluginInfo and adds it to the list
>
> The Win32 PluginInfo constructor (where the calls to LoadLibrary and
> GetProcAddress are located) will try to find the plugin_enum function.
> If it does, it calls it to find what modules are supported; if not, it
> assumes the plugin supports one module with the same base name as the
> DLL.
This is WAY too complicated... It doesnt have to be! Why dont we let
the dynamic libs register the plugins they can create? Something
like...
extern "C"{
void init(){
extern map< string, Module*(*)() > creators;
creators["reader"]=create_reader;
creators["writer"]=create_writer;
creators["wavout"]=create_wavout;
}
}
Would it be simpler?
>
> | Another point... Each plugin is statically linked with the
> | environment.lib library. Would it be worth it to make all the plugins
> | share one instance of this library?
>
> Yes, it probably would. Options are:
> 1) Turn the environment into a DLL and have the plugins and UI reference
> it
> 2) Export the environment functionality from the UI
>
> I think (2) sounds best. On Windows the plugin DLL can import from, say,
> radiator.exe; I'm not sure of the Posix situation but I think it's
> simpler there.
Hmmm... I dont understand what would mean in option 2)... Could you
explain?
Pat Mahoney, no 22
|
|
From: Tim R. <ti...@ga...> - 2002-08-19 11:08:19
|
On Mon, 19 Aug 2002 01:13:08 -0400 Patrick Mahoney <pat...@po...> wrote: | > The create() function ought to take a module ID so that we can put | > multiple modules in each plugin library (saves code, memory, disk space, | > etc.). I'm going to put this into the Windows version, along with a | > module_enum() function, and see how it works. | | The way it is now, the user requests the instanciation of a plugin via | its name, a simple string. The Environment object concatenates the | name with the .so extention (under unix), and finds the 'create' | method which is assumed to create an instance corresponding to the | string demanded by the user. | | If you want to allow one .so file to contain several plugins, the | string submitted by the user cannot be associated with unambiguously | with one plugin. If we want to do this, i would rather like the plugin | to register all of its 'create' functions in a stl::map< string , | Module*(*)() > kinda data structure, like the doc/dynlib-c++.html | suggests to do. OK, what I've got so far: -- Environment maintains a list of PluginInfo classes, each of which represents one plugin -- PluginInfo knows how to load a plugin and ask it what modules it supports (it should also know how to unload it when the time comes) -- Environment::create can walk the list of PluginInfo's, asking each one if it supports the given module. If it does, it calls through the create pointer that PluginInfo saved -- If no PluginInfo claims to know about the module, the environment creates a new PluginInfo and adds it to the list The Win32 PluginInfo constructor (where the calls to LoadLibrary and GetProcAddress are located) will try to find the plugin_enum function. If it does, it calls it to find what modules are supported; if not, it assumes the plugin supports one module with the same base name as the DLL. | Another point... Each plugin is statically linked with the | environment.lib library. Would it be worth it to make all the plugins | share one instance of this library? Yes, it probably would. Options are: 1) Turn the environment into a DLL and have the plugins and UI reference it 2) Export the environment functionality from the UI I think (2) sounds best. On Windows the plugin DLL can import from, say, radiator.exe; I'm not sure of the Posix situation but I think it's simpler there. | Plugin ideas... | - wave visualizer? it could pipe the data to some graphical | application... | - fourier-transformer? it would apply a fourier transform to the data | and pipe it to some similar graphical app so we can vizualize it in | the frequency domain... Hmm... sounds good. I guess the visualisation things need to wait for the GUI. | Hrmm... Does windows implement sysv or posix ipcs? :) Like what? Signals -- yes, but it won't give you any signals other than what you generate yourself. Pipes -- yes, it's got those. -- Tim Robinson <ti...@ga...> |
|
From: Patrick M. <pat...@po...> - 2002-08-19 05:13:14
|
> The create() function ought to take a module ID so that we can put > multiple modules in each plugin library (saves code, memory, disk space, > etc.). I'm going to put this into the Windows version, along with a > module_enum() function, and see how it works. The way it is now, the user requests the instanciation of a plugin via its name, a simple string. The Environment object concatenates the name with the .so extention (under unix), and finds the 'create' method which is assumed to create an instance corresponding to the string demanded by the user. If you want to allow one .so file to contain several plugins, the string submitted by the user cannot be associated with unambiguously with one plugin. If we want to do this, i would rather like the plugin to register all of its 'create' functions in a stl::map< string , Module*(*)() > kinda data structure, like the doc/dynlib-c++.html suggests to do. Another point... Each plugin is statically linked with the environment.lib library. Would it be worth it to make all the plugins share one instance of this library? Plugin ideas... - wave visualizer? it could pipe the data to some graphical application... - fourier-transformer? it would apply a fourier transform to the data and pipe it to some similar graphical app so we can vizualize it in the frequency domain... Hrmm... Does windows implement sysv or posix ipcs? :) Pat Mahoney, no 22 |
|
From: Tim R. <ti...@ga...> - 2002-08-18 22:53:04
|
On Sun, 18 Aug 2002 05:34:59 -0400 Patrick Mahoney <bo...@in...> wrote: [...] | PM22 - Port the dynamic lib loading functionnality to windows. | | -> Hi Tim! :) The create() function ought to take a module ID so that we can put multiple modules in each plugin library (saves code, memory, disk space, etc.). I'm going to put this into the Windows version, along with a module_enum() function, and see how it works. -- Tim Robinson <tim...@ic...> |
