Menu
▾
▴
feapi-discussion — Discussions or questions about the API, its practical use, or anything related.
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(27) |
Apr
(2) |
May
(4) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(64) |
Feb
(3) |
Mar
(103) |
Apr
(51) |
May
(21) |
Jun
(11) |
Jul
|
Aug
(25) |
Sep
(12) |
Oct
|
Nov
(18) |
Dec
(69) |
| 2007 |
Jan
(18) |
Feb
|
Mar
(61) |
Apr
(4) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
(11) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: alexander l. <le...@zp...> - 2005-03-14 20:46:48
|
Hi, I did no check in anything yet, because I am not sure how to proceed: I think the header file can be checked-in after we agreed on the naming, but should the documentation, the internal base class and the example plug/host also being check-in, despite the fact that they are not completely up-to-date? They will work more or less, though... Then, the next steps would be (without order): - rewrite plug base class - rewrite example host - rewrite example plug - update documentation (API, plug, host) - make a rudimentary project home page for presentation - announce final draft version Further topics? Priorization? Cheers, (a) -- dipl. ing. alexander lerch zplane.development http://www.zplane.de holsteinische str. 39-42 D-12161 berlin fon: +49.30.854 09 15.0 fax: +49.30.854 09 15.5 |
|
From: alexander l. <le...@zp...> - 2005-03-14 18:27:51
|
corresponding to our private discussions, now look at this: - nice _t's at the end of each typedef, omitting all begin/end underscores - no underscores for constant defines/enums, but a FEAPI_k prefix instead however, the typedefs are still with prefix feapi, not FEAPI_ (note that all functions are also only typedefs). I can change all the nice small feapi-prefixes to really big fat FEAPI_-prefixes if you wish, although I somewhat prefer it this way, as you might read between the lines... Your opinions? Cheers, (a) -- dipl. ing. alexander lerch zplane.development http://www.zplane.de holsteinische str. 39-42 D-12161 berlin fon: +49.30.854 09 15.0 fax: +49.30.854 09 15.5 |
|
From: Koen T. <Koe...@UG...> - 2005-03-14 15:59:17
|
Oh, one more thing: I would like to see "FEAPI" instead of "feapi", because it's an abbreviation (like API). Can that still be changed? Koen >> feapi >> .build >> ..win32 >> ...example plug >> ...example host >> ..unix >> ...example plug >> ...example host >> .incl >> .src >> ..API >> ..example plug >> ..example host >> ..incl >> .doc >> ..API >> ..example plug >> ..example host |
|
From: Koen T. <Koe...@UG...> - 2005-03-14 15:55:58
|
On Monday, March 14, 2005 3:21 PM [GMT+1=CET], Gunnar Eisenberg <xxx...@nu...> wrote: > Concerning these things I would vote for alternative b which means not > splitting up everything. Me too. Koen PS In any case, CVS allows you to make "module views" that only contain a subset of directories or files from your whole source tree. So, we could use that if needed later. > -----Original Message----- > From: fea...@li... > [mailto:fea...@li...] On Behalf Of > alexander lerch > Sent: Monday, March 14, 2005 3:14 PM > To: fea...@li... > Subject: [Feapi] cvs directory structure > > Hi, > > the discussion about the CVS directory structure is quite important, > since it is not easy to change an existing cvs directory structure. > > If we want to separate API, example plug and example host in the top > level, we end up like this for each of the three: > > API > .build > ..win32 > ..unix > .incl > .src > .doc > > One possible problem is that all projects require the same (API) > header file. > > Alternatively, we could try something similar like it is now: > > feapi > .build > ..win32 > ...example plug > ...example host > ..unix > ...example plug > ...example host > .incl > .src > ..API > ..example plug > ..example host > ..incl > .doc > ..API > ..example plug > ..example host > > As for the first approach, I think it will be difficult to separate > API and example plug, while it might be more easily possible to > separate both from the example host. > The second approach OTOH more or less requires everybody to download > all sources which might be confusing to some people. > > I don't know..., are there alternatives? > > Cheers, > (a) |
|
From: Gunnar E. <eis...@nu...> - 2005-03-14 14:19:39
|
Concerning these things I would vote for alternative b which means not splitting up everything. Cheers, Gunnar -----Original Message----- From: fea...@li... [mailto:fea...@li...] On Behalf Of alexander lerch Sent: Monday, March 14, 2005 3:14 PM To: fea...@li... Subject: [Feapi] cvs directory structure Hi, the discussion about the CVS directory structure is quite important, since it is not easy to change an existing cvs directory structure. If we want to separate API, example plug and example host in the top level, we end up like this for each of the three: API .build ..win32 ..unix .incl .src .doc One possible problem is that all projects require the same (API) header file. Alternatively, we could try something similar like it is now: feapi .build ..win32 ...example plug ...example host ..unix ...example plug ...example host .incl .src ..API ..example plug ..example host ..incl .doc ..API ..example plug ..example host As for the first approach, I think it will be difficult to separate API and example plug, while it might be more easily possible to separate both from the example host. The second approach OTOH more or less requires everybody to download all sources which might be confusing to some people. I don't know..., are there alternatives? Cheers, (a) -- dipl. ing. alexander lerch zplane.development http://www.zplane.de holsteinische str. 39-42 D-12161 berlin fon: +49.30.854 09 15.0 fax: +49.30.854 09 15.5 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Feapi-discussion mailing list Fea...@li... https://lists.sourceforge.net/lists/listinfo/feapi-discussion |
|
From: alexander l. <le...@zp...> - 2005-03-14 14:14:02
|
Hi, the discussion about the CVS directory structure is quite important, since it is not easy to change an existing cvs directory structure. If we want to separate API, example plug and example host in the top level, we end up like this for each of the three: API .build ..win32 ..unix .incl .src .doc One possible problem is that all projects require the same (API) header file. Alternatively, we could try something similar like it is now: feapi .build ..win32 ...example plug ...example host ..unix ...example plug ...example host .incl .src ..API ..example plug ..example host ..incl .doc ..API ..example plug ..example host As for the first approach, I think it will be difficult to separate API and example plug, while it might be more easily possible to separate both from the example host. The second approach OTOH more or less requires everybody to download all sources which might be confusing to some people. I don't know..., are there alternatives? Cheers, (a) -- dipl. ing. alexander lerch zplane.development http://www.zplane.de holsteinische str. 39-42 D-12161 berlin fon: +49.30.854 09 15.0 fax: +49.30.854 09 15.5 |
|
From: Gunnar E. <eis...@nu...> - 2005-03-14 14:08:18
|
I vote for: typedef void* _feapiPlugInstance_; Instead of the struct. Best, Gunnar -----Original Message----- From: fea...@li... [mailto:fea...@li...] On Behalf Of alexander lerch Sent: Monday, March 14, 2005 2:52 PM To: fea...@li... Subject: [Feapi] API naming conventions Hi, I did some renaming for the functions, structures, etc., please find the header in the attachment. Is this ok as it is, or shall we change some more things? Due to "historic" reasons, we have a _feapiPlugInInstance_ structure that now contains only the void-pointer to the instance itself. My question is: Do you see any reasons to keep this as structure or should we simply make a typedef void* _feapiPlugInstance_; ? Cheers, (a) -- dipl. ing. alexander lerch zplane.development http://www.zplane.de holsteinische str. 39-42 D-12161 berlin fon: +49.30.854 09 15.0 fax: +49.30.854 09 15.5 |
|
From: alexander l. <le...@zp...> - 2005-03-14 14:02:13
|
Sorry, that was the old version. Grmph. Next try... (a) alexander lerch wrote: > Hi, > > I did some renaming for the functions, structures, etc., please find the > header in the attachment. Is this ok as it is, or shall we change some > more things? > > Due to "historic" reasons, we have a _feapiPlugInInstance_ structure > that now contains only the void-pointer to the instance itself. My > question is: Do you see any reasons to keep this as structure or should > we simply make a > typedef void* _feapiPlugInstance_; > ? > > Cheers, > (a) > > > -- dipl. ing. alexander lerch zplane.development http://www.zplane.de holsteinische str. 39-42 D-12161 berlin fon: +49.30.854 09 15.0 fax: +49.30.854 09 15.5 |
|
From: alexander l. <le...@zp...> - 2005-03-14 13:51:56
|
Hi, I did some renaming for the functions, structures, etc., please find the header in the attachment. Is this ok as it is, or shall we change some more things? Due to "historic" reasons, we have a _feapiPlugInInstance_ structure that now contains only the void-pointer to the instance itself. My question is: Do you see any reasons to keep this as structure or should we simply make a typedef void* _feapiPlugInstance_; ? Cheers, (a) -- dipl. ing. alexander lerch zplane.development http://www.zplane.de holsteinische str. 39-42 D-12161 berlin fon: +49.30.854 09 15.0 fax: +49.30.854 09 15.5 |
|
From: Gunnar E. <eis...@nu...> - 2005-03-14 12:43:38
|
Hi there,
1. Concerning the FEAPI_PlugCanDo I would suggest the following. What do
you think of it?
////////////////////////////////////////////////
enum eFEAPI_Properties
{
_FEAPI_SAMPLE_RATE_ = 0,
_FEAPI_NUMBER_OF_CHANNELS_ = 1,
};
typedef int (*_FEAPI_PlugCanDo_)(eFEAPI_Properties iPlugProperties,
void* pvData);
// example-calls:
float fSampleRate=44100;
if (FEAPI_PlugCanDo(_FEAPI_SAMPLE_RATE_, (void*)&fSampleRate))
printf("A sample rate of 44100 Hz is supported by this
plugin.\n");
int iNumberOfChannels=6;
if (FEAPI_PlugCanDo(_FEAPI_VERSION_, (void*)&iNumberOfChannels))
printf("This plugin can handle 6 channels.\n");
////////////////////////////////////////////////
2. Source Forge directory structure
I would prefer to separate example host, example plugin and API.
3. Naming Conventions
Ok, lets stick with the z.plane-conventions with additional "feapi"
prefixes (after the underscores, Hungarian-notations etc.)
4. Ports
No, I don't need the word "ports" ;-). I just want to make clear that
the description is for channels, feature-ins, and feature-outs. Better
ideas for a name which is an umbrella for all three are welcome.
Cheers,
Gunnar
|
|
From: Gunnar E. <eis...@nu...> - 2005-03-14 11:11:25
|
------------------------------------------ Dipl.-Ing. Gunnar Eisenberg TU Berlin - Secretary EN 1 Communication Systems Group Phone: +49 30 314 29418 Fax: +49 30 314 22514 http://www.nue.tu-berlin.de/wer/eisenberg/ |
