Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

RFC: REBOL Home Multimedia Platform (RHMP)

 [1/14] from: robert:muench:robertmuench at: 29-Dec-2001 1:49


Hi, I'm not very happy with all the HiFi, Video, Sound etc. components used for home entertainment because to much devices, to many cables and to few features. What I need is a nice and extendable all-in-one device. As it looks like, none of the big consumer electronic manufacturers are going to release such a device in the near future, I'm going to do it myself! Well, to be honest, there are a lot of other groups working on those projects but however, mine will have a big difference: It will use Rebol/View for the GUI :-)) If you never have looked into such projects have a look at http://www.showshifter.com which is exactly such a thing I'm thinking about. Of course some more features and better usability and support. I'm not sure how to do it with Rebol yet, doing the GUI shouldn't be to hard. IMO we need an interface DLL (I call it DLL here but the RHMP should work on other platforms too) that will provide calls for the following functions: - Play video files (avi, mpeg, asf, ...) - Play sound files (mp3, wma, audio-cd) - Play DVD discs - Display TV (analog and digital) - Can be used as a digital video recorder - Can grab CDs and convert them to ... - All functions can be controled by a IR remote control The interface should be the same for all platforms, so that we can use one Rebol/View file and just have several interface implementations. IMO this thing needs to be done in C/C++. Does anyone has experience with programming those functions on Windows/Linux/Mac? Are there are any others here that are interested in such a project? What do you think? Any more ideas? -- Robert M. Münch IT & Management Freelancer Mobile: +49 (0)177 2452 802 Fax : +49 (0)721 8408 9112 Web : http://www.robertmuench.de

 [2/14] from: jasonic:cunliffe:verizon at: 28-Dec-2001 22:18


Hi Robert ..yes a tantalizing and _very_ ambitious project. Perhaps I misundertsand you, but my first reaction is that by the time you have added all that it is barely REBOL any longer - it has tuirned in to a hige project. What I mean is you seem to be taking on the highly complex world of mutiple media formats. REBOL is small and sweet laregly becuase it avoids all that. REBOL/View is small and sweet becuase it applies a few simple graphics tricks within a tight paradigm. No big overheard, litle or no dependency. Maximum isable effect. A soon as you add devices, video etc, you run up against so many nasty obstacles: 1. techno-politics I mean things like MSDirectX vs. Quicktime vs. RealNetwords all vying for control to be THE system player 2. versionitis same as oabove plus incompatibilities between software, content, OS and media libraries 3. development time, testing and distibution/installation 4. Financial Costs and technical skills needed for suchd evelopment 5. size and perfomances issues 6. licensing issues 7. upgrade and maintentance How to support all that? It better be really good and up to date, or why will anyone bother beyond curiosity, as programming excercise, or deepest rebol evangelism? There are a number of poeple who have been working hard to do integrate media adn virtualize them. The music editing odtwaer adn plugins architecure market shows how far we've come in just the past 5 years. Almost everthing one has wanted/needed to do in hardware is now virtualized for audio and video. An very intersting toolkit which opens some of this up is Miller Puckette's PD [Pure Data] plus GEM and other cool extensions: http://www.crca.ucsd.edu/~msp/software.html http://www.pure-data.org/ http://www.danks.org/mark/ Because PD comes frmo a an experimetental signal processing and live performance heritage, it tends to be more aware of physcial and virtual i/o needs. The paradigm is a wonderful obejct-oreientd patchbay. KeyKit is another but strictly focused on MIDI. KeyKit is A brilliant relationship between langauge data objects and GUI: http://www.nosuch.com/keykit/ Both of the above are well worth playing around with becase they have some great ideas adn effort in them already. Projects like the one you propose for REBOL/View could surely benefit. Perhaps a clear step then is to integrate rather thant reinvent such effort. I believe the TAO Group's system is one such serious candidate. Have you looked at that and way's to leverage it with REBOL? http://tao-group.com/2/tao/index.html As it happens, I was just today looking again at PyGame, the Python package built on top of SDL, a cross-platform game developer's library. http://pygame.org/ http://pygame.org/docs/index.html http://www.libsdl.org/ <quote> Simple DirectMedia Layer is a cross-platform multimedia library designed to provide fast access to the graphics framebuffer and audio device. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power." Simple DirectMedia Layer supports Linux, Win32, BeOS, MacOS, Solaris, IRIX, and FreeBSD. SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, Eiffel, ML, Perl, PHP, Python, and Ruby. </quote> This includes access to CD's joysticks and various i/o. The frambuffering of SDL may adapt well to REBOL/Views heritage also .. I would imagine there is lots to be learned from that work alone. Translating Python to REBOL should be prerty easy since Python is very clear and consistent. Like Python itself, most packages and modules are free and opensource. An easy proof of concept strategy is to use Python +REBOL. Python runs on a very wide choice of platforms like REBOL so sintalaltion should not be too hard. Their is a rich array of libraries, good documentation, books, community etc. My point is that ERBOL + Python are both great for rapid protiypinga dnfavour a very modular approach. Get the core structreu in REBOL establasish ed usign Python conmpnents, then port and intefgraet according to needs priorities. Licensing and other issues of the Python sections should not distract you from you main REBOL/View vision. THE site for reviewing contributed modules: http://www.vex.net/parnassus cheers ./Jason

 [3/14] from: petr:krenzelok:trz:cz at: 29-Dec-2001 6:28


Well, multimedia - Carl's second name - do you remember? :-) Some time ago I asked Holger, if Rebol/View could be as an general GUI engine for some underlying embedded OS. IIRC his answer was something like that it is NOT all that easy - you still need drivers which know how to talk to your hw. I think that you can only think about Rebol/View as an Desktop replacement, or just maybe plain and simply - start Rebol/View desktop once your OS is loaded .... As for multimedia - as Holger mentioned too - you have to deal with various formats, owned by various companies. Don't expect Rebol staying small in size, while implementing .avi, .divx, .mpeg, .mp3., .wav etc support itself. I think RT should just create native engines (ports), providing you a standardised/unified bridge to underlying system capabilities. I know that you, the same as me, the same as others, would like to see MagmaOS (RebOS) to come to life one day, and be proud of small, efficient, STAND-ALONE rebol OS, not just Rebol hosted on some platform. But look at Amiga and their take to introduce native AmigaDE (Tao Intent based) OS - no luck for more than 3 years already ...I think that such scenario is not even practical to Rebol - Tao for e.g. has nice Virtual Processor (along with hw abstraction layer) architecture, and you can implement some media player directly in VP code = Rebol code for us. Can you imagine implementing .mp3 decoding engine directly in Rebol code? Sadly - Rebol is tooooo slow here and impossible to compile ... ... So you need a library interface. We have one. I remember Jeff stating there were some changes to library interface, but those changes were not introduced yet. Anyway - it is easy (very easy) to speed the thingy up. I for one, created Rebol/View face native library effect. Well, not me, but my Linux friend. You just send your face referencing word to library, and you suddenly have access to image data buffer. We messed image data a bit, did refresh on face, and voila, it was there. That's exactly the way I think Morpheus will use. They surely are not implementing multimedia players 1) in Rebol - lack of speed 2) themselves at all. I am not sure .e.g. Windows media player provides you any kind of api, allowing you to receive pointer to image in memory, once rendered. It would be cool, if View could display it inside your face, so cool .... I asked about possibility to have media player window embedded inside View face, but RT have not provided me with clear answer, so I don't know .... Another thing is asynchronicity - remember - once you do something in your library code - you are simply there, and imo rest of the Rebol just sleeps. We would also need something along the Amiga device model - ability to call libraries (interfaces) asynchronously. I talked with Holger on IOS conference, and he told me, that RT plans to rework timers some time later, to work along the lines of Amiga device model, so be of more usage in various situations ... Cyphre also sent few enhancement requests to Holger, IIRC. E.g. according to Cyphre, ability to freeze/unfreeze face events, while face is still in display, would allow us to implement basic scheduling mechanism ("task" priority), based upon timing, directly in Rebol level. Now back to your idea. What hardware are you talking about? If you think you will implement one yourself, so better forget it, if you don't have enough money. I am part of small team doing some hw stuff, and man - it costs money .... and time .... So let's imagine you will use some 3rd party hw. OK - is the OS delivered with it? Well, to be honest, - if I would implement some kind of set-top-box, I would go with QNX Rtp, even if it costs money. You pay for the support and you get what you paid for. The OS covers small and efficient kernel, is message based, nicely scales (QNet capability). Photon architecture is nice too. It provides you with POSIX compliancy, so you can port from Uni*es "easily". It also provides you multimedia layers. If I would not go with QNX, then I would considered some kind of embedded Linux, but I am not sure of support here ... Tao for e.g. has yet to prove its ability to be used directly on various hardware set-ups ... But - if you think of Rebol/View as an GUI/presentation layer only, it could be done, although the lack of proper browser plug-in is critical imo, as Rebol itself is not capable/fast engough, for browser to be implemented in it. Imagine e.g. mailer app. You an do it with rebol, but how do you display html based messages? Our company Lotus Notes team switched to html based emails as a default set-up. Well, you can say - I will display it in browser thru browse feature, but - it is pretty inconsistent as far as mailer app is concerned ... there is probably even more issues ... It would be interesting to know Holger's or Carl's opinion, as they hold the keys to Rebol future, and I can bet they already thought about Rebol possibilities in multimedia, set-top-box market, as they both come from Amiga/set-top-box land .... Cheers, -pekr-

 [4/14] from: slok00:ya:hoo at: 29-Dec-2001 13:25


Nokia has a device called the Media Terminal http://www.nokia.com/multimedia/mediaterminal.html And they have actually started the Open Standards Terminal Developers Network to support the Media Terminal https://www.ostdev.net/servlets/DomainHome?redirect=SSL&JServSessionIdservlets=l29vhgoqt1 Ericsson themselves also has a product called the Nanocube which resembles the Cobalt Cube. However, it is more oriented towards being an appliance for the home and is based on Linux. I have the specification for the Nanocube and can email the anyone who is interested in finding out more. Just give me a "ping" at [slok00--yahoo--com] While I don't think any of the products will fulfill all your needs, I strongly believe they are moving towards the idea. Sony is also one to watch as they have previously licensed BeIA from Be Inc. Of course, with the demise of Be, and Palm which acquire Be in trouble with Xerox, it is relatively unclear how things will uncover in the coming months. But Sony is definitely a player that will be moving towards such a concept. They already have a whole range of appliance and a brand name that customer is accustomed to. They have already tout their memory stick for use across multiple devices. It is a matter of time when they will come out with a device that can integrate and control all the other devices. Just a thought here. YekSoon At 01:49 AM 12/29/2001 +0100, you wrote:

 [5/14] from: robert:muench:robertmuench at: 29-Dec-2001 9:35


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 9>>
> simple graphics tricks within a tight paradigm. No big overheard, litle or > no dependency. Maximum isable effect.
Hi, no I don't want to add all this to Rebol. Why should I? There are all those programs around that can handle all these applications. I just want to use Rebol as a common front-end to all these applications.
> 1. techno-politics > I mean things like MSDirectX vs. Quicktime vs. RealNetwords all vying for > control to be THE system player
I don't care to much. Just add what's needed to get the feature run. In the first step I would need: DVB TV, Mpeg/AVI playback, MP3 Sound IIRC the mediaplayer on Windows can handle most of this (only TV is missing) and I'm sure it's an ActiveX component we can use.
> 2. versionitis > same as oabove plus incompatibilities between software, content, OS and > media libraries
Hmm... the concept should be open, if you miss something you can add it.
> 3. development time, testing and distibution/installation
Well, that's the petty with open-source projects but no problem. It's never to late to start.
> 4. Financial Costs and technical skills needed for suchd evelopment.
That's the challange to take :-))
> 5. size and perfomances issues
Solvable.
> 6. licensing issues
For private use I don't care (to be more exactly: I don't have to care in Germany).
> 7. upgrade and maintentance > How to support all that? It better be really good and up to date, or why > will anyone bother beyond curiosity, as programming excercise, or deepest > rebol evangelism?
I don't know, because it's fun, it's useful and it has value?
> There are a number of poeple who have been working hard to do integrate > media adn virtualize them.
Again, I don't want to virtualize them. I just want to integrate all the play-back applications with one front-end. Robert

 [6/14] from: robert:muench:robertmuench at: 29-Dec-2001 9:35


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 6>>
> And they have actually started the Open Standards Terminal Developers > Network to support the Media Terminal
https://www.ostdev.net/servlets/DomainHome?redirect=SSL&JServSessionIdservlets=l 29vhgoqt1 Hi, I don't like all these things because it takes those companies to long to produce a quality product. And you can be sure it's missing the feature you want to have because of company politics. I don't care about company politics and I'm not going to be their beta-tester. Sorry, I bought to much techie-stuff to early and it never was worth the money...
> Ericsson themselves also has a product called the Nanocube which resembles > the Cobalt Cube. > However, it is more oriented towards being an appliance for the home and is > based on Linux.
Same here... just ideas.
> While I don't think any of the products will fulfill all your needs, I > strongly believe they are moving > towards the idea.
Perhaps one day. But I want to control the feature set and how it's done. Do you think these companies will support MP3 files in the future? I don't, they will crippel things with all kind of: you are not allowed to use XYZ this way, because we don't like it. Thank you but I can decide this myself.
> Sony is also one to watch as they have previously licensed BeIA from Be Inc.
Yeah, but unfortunately BeOS is dead and I'm sure Palm will succeed in breaking it down to useless state... Robert

 [7/14] from: robert:muench:robertmuench at: 29-Dec-2001 9:35


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 3>>
> Subject: [REBOL] Re: RFC: REBOL Home Multimedia Platform (RHMP) > Well, multimedia - Carl's second name - do you remember? :-)
Hi, yes I do ;-))
> Some time > ago I asked Holger, if Rebol/View could be as an general GUI engine for
<<quoted lines omitted: 3>>
> replacement, or just maybe plain and simply - start Rebol/View desktop > once your OS is loaded ....
That's exactly what I would like to do. Use all the existing applications and the corresponding SDKs and integrate them into one common Rebol/View front-end.
> As for multimedia - as Holger mentioned too - you have to deal with > various formats, owned by various companies. Don't expect Rebol staying > small in size, while implementing .avi, .divx, .mpeg, .mp3., .wav etc > support itself.
As said, I don't want to use Rebol to handle the processing, therefore we have enough applications, I want to use it as control-center.
> I think RT should just create native engines (ports), > providing you a standardised/unified bridge to underlying system > capabilities.
That's something I have been thinking about too. Instead of developing a Rebol useable library (DLL) we could create a protocoll that an interface application can handle. It's more the idea of a web-service.
> I know that you, the same as me, the same as others, would > like to see MagmaOS (RebOS) to come to life one day, and be proud of
<<quoted lines omitted: 6>>
> for us. Can you imagine implementing .mp3 decoding engine directly in > Rebol code? Sadly - Rebol is tooooo slow here and impossible to compile ...
Hey, of course it's nice to get everything at once but I'm more realistic here: This won't happen for some long time, that's why I preferr the best-of-breed approach here.
> Anyway - it is easy (very easy) to speed the > thingy up. I for one, created Rebol/View face native library effect. > Well, not me, but my Linux friend. You just send your face referencing > word to library, and you suddenly have access to image data buffer. We > messed image data a bit, did refresh on face, and voila, it was there.
That's a good starting point. Even if this uses undocumented features, I'm sure RT will hear our needs and see what they can do.
> I am not sure .e.g. Windows media player provides you any kind of api, > allowing you to receive pointer to image in memory, once rendered.
I didn't checked it out yet, but I'm 90% sure it does. It's just an ActiveX control.
> It would be cool, if View could display it inside your face, so cool .... I > asked about possibility to have media player window embedded inside View > face, but RT have not provided me with clear answer, so I don't know ....
It shouldn't be to hard to test this.
> Another thing is asynchronicity - remember - once you do something in > your library code - you are simply there, and imo rest of the Rebol just > sleeps.
Not mandatory: We can use a TCP protocoll and Rebol just sends a command like: play video myvideo.mpg location 100x200 size 640x320
> Now back to your idea. What hardware are you talking about? If you think > you will implement one yourself, so better forget it, if you don't have > enough money. I am part of small team doing some hw stuff, and man - it > costs money .... and time ....
Just use the things you have. Of course it will grow over time but that's OK. BTW: I did develop hardware myself, well we did develop and produce our own processor with > 10 Mio. transistors ;-))
> So let's imagine you will use some 3rd party hw. OK - is the OS > delivered with it?
No, just use the one you have. For me, it's mainly Windows but Linux should be fine too.
> But - if you think of Rebol/View as an GUI/presentation layer only, it > could be done, although the lack of proper browser plug-in is critical > imo, as Rebol itself is not capable/fast engough, for browser to be > implemented in it.
You can use IE as ActiveX control ;-)) you don't need all the stuff around it, you can just use the rendering part.
> Imagine e.g. mailer app. You an do it with rebol, but > how do you display html based messages?
Either with IE or use Outlook controls.
> It would be interesting to know Holger's or Carl's opinion, as they hold > the keys to Rebol future, and I can bet they already thought about Rebol > possibilities in multimedia, set-top-box market, as they both come from > Amiga/set-top-box land ....
Yes, this really would help to get a feeling for the direction they are thinking about. However, I know my words sound to easy to do it and yes, I know it won't be perfect. But do you have an alternative solution? The German c't (http://www.heise.de) has started such a project and quite a lot of people have build up such systems. So it's possible... Robert

 [8/14] from: petr:krenzelok:trz:cz at: 29-Dec-2001 14:13


Robert M. Muench wrote:
>>I think RT should just create native engines (ports), >>providing you a standardised/unified bridge to underlying system
<<quoted lines omitted: 3>>
>useable library (DLL) we could create a protocoll that an interface application >can handle. It's more the idea of a web-service.
yes, that could do it. We should probably use port/scheme type aproach, as with sound, encryption, etc. for domains specific tasks ... and use object/handler to store the handling code ... but I thought of .dll aproach too and it is imo doable too. You simply create some kind of API, callable the same way thru all rebol platform, and then you would create also platform specific layer ... I don't want to see e.g. some kind of direct call to some clumsy ActiveX media player interface, if I can't use it on other Rebol platforms in the same way ... Well, if, however, keeping all Rebol platforms in the game is not possible, then even some kind of .dll interface is still better than no interface at all. ... I think that time will come, when RT realises that both /shell and /library interfaces are minority revenue stream for them, and will release both components to free Rebol products, otherwise ppl will use capabilities sporadically ....
>>Anyway - it is easy (very easy) to speed the >>thingy up. I for one, created Rebol/View face native library effect.
<<quoted lines omitted: 4>>
>That's a good starting point. Even if this uses undocumented features, I'm sure >RT will hear our needs and see what they can do.
I will look for the source code on my notebook. I thought that we could create some rebol effects library, which could work thru most platforms that way ...
>>Another thing is asynchronicity - remember - once you do something in >>your library code - you are simply there, and imo rest of the Rebol just >>sleeps. >> > >Not mandatory: We can use a TCP protocoll and Rebol just sends a command like: > play video myvideo.mpg location 100x200 size 640x320 >
tcp protocol? You would have to create separate app - bridge, which would have to listen to Rebol app on one side, while talking to native environment on the other side ...
>>now back to your idea. What hardware are you talking about? If you think >>you will implement one yourself, so better forget it, if you don't have
<<quoted lines omitted: 4>>
>BTW: I did develop hardware myself, well we did develop and produce our own >processor with > 10 Mio. transistors ;-))
heh, that's cool :-) Rebol CPU anyone? :-)
>>But - if you think of Rebol/View as an GUI/presentation layer only, it >>could be done, although the lack of proper browser plug-in is critical
<<quoted lines omitted: 3>>
>You can use IE as ActiveX control ;-)) you don't need all the stuff around it, >you can just use the rendering part.
and it surely ... will work on other platforms, the same way, right? ;-)
>>Imagine e.g. mailer app. You an do it with rebol, but >>how do you display html based messages? >> > >Either with IE or use Outlook controls. >
never! For me e.g., the only one open and multiplatform mailer is - Mozilla .... what is more - it stores emails as sendmail on Linux does - in plain text form, so it is parseable by Rebol itself for e.g. ... now the only problem really is that html embedded part ...maybe Mozilla contains any kind of embeddable html (gecko) container too? No Outlook virus, please ;-) btw: QNX, Suse, RedHat and others seem to go similar route? http://www.eclipse.org/ Cheers, -pekr-

 [9/14] from: robert:muench:robertmuench at: 29-Dec-2001 16:22


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 7>>
> to see e.g. some kind of direct call to some clumsy ActiveX media player > interface, if I can't use it on other Rebol platforms in the same way ...
Hi, yep that's the way I thought of. Others can pick the wrapper library and implement the interface for their platform.
> I will look for the source code on my notebook. I thought that we could > create some rebol effects library, which could work thru most platforms > that way ...
Ok, just send it to me if you found it. I have a look at it.
> tcp protocol? You would have to create separate app - bridge, which > would have to listen to Rebol app on one side, while talking to native > environment on the other side ...
Right, but with this you don't need the /library extension and the RHMP could be used by anyone.
>>You can use IE as ActiveX control ;-)) you don't need all the stuff >>around it, you can just use the rendering part. > and it surely ... will work on other platforms, the same way, right? ;-)
Oh yes ;-))! Just plug-in something else... we only need a very small interface.
> never! For me e.g., the only one open and multiplatform mailer is - > ...
Well, than use Mozialla and plug this in. I really don't care, there just need to be enough adaptors provided for all kind of proggys the people use. Robert

 [10/14] from: petr:krenzelok:trz:cz at: 29-Dec-2001 18:17


Robert M. Muench wrote:
>>I will look for the source code on my notebook. I thought that we could >>create some rebol effects library, which could work thru most platforms >>that way ... >> > >Ok, just send it to me if you found it. I have a look at it. >
REBOL [] do %lib-rgb.r img: load %coins.jpg parse img [img-ptr:] ; a cool "hack" :-) screen: layout [ im: image img button "Change" [ scale-color img-ptr (length? img-prt) / 4 show im ] ] view screen ---------------- ; lib-rgb source ... rgb-lib: load/library %some-dll.dll scale-color: make routine! [ str [string!] len [integer!] ] rgb-lib "scalecolor" ----------------- ; .dll source ... #include <stdio.h> __declspec (dllexport) void scalecolor(unsigned char *imagedata, int numofpixels) { int i; for(i=0;i<numofpixels;i+=2) { unsigned char pixel=( (i & 1)!=0 ? 0xff : 0x00); imagedata[4*i]=pixel; imagedata[4*i+1]=pixel; imagedata[4*i+2]=pixel; imagedata[4*i+3]=0x00; } } ; it will simply change each second column in the image to black color .... (the example probably doesn't preserve alpha channel ....) it is fast - very fast. I can't imagine doing pick/poke upon each pixel of image on a larger image. General convolution mechanism is not accessible from Rebol level. The question is - if you would like to create e.g. some fire effect (having face with some 20/sec fps timer set) how vital would be such often library access ...
>>tcp protocol? You would have to create separate app - bridge, which >>would have to listen to Rebol app on one side, while talking to native >>environment on the other side ... >> > >Right, but with this you don't need the /library extension and the RHMP could be >used by anyone. >
so you are skilled enough to create small listening server in C code? Well, we could use Rebol itself - tcp ports are easy, and we could use View/Pro and Encap the resulting app ... you would be even easily able to set filters to certain tcp address access ...
>>>You can use IE as ActiveX control ;-)) you don't need all the stuff >>>around it, you can just use the rendering part.
<<quoted lines omitted: 7>>
>Well, than use Mozialla and plug this in. I really don't care, there just need >to be enough adaptors provided for all kind of proggys the people use. Robert
Now I understand your intentions ..... it would be interesting to hear RTs plans for such area though ... -pekr-

 [11/14] from: ptretter:charter at: 29-Dec-2001 7:52


And to add to that: REBOL is an interpreted language, therefore the speed that is usually required for handling the formats mentioned is not best suited for REBOL. And encap is not a solution either as it does NOT compile :( REBOL scripts. I do however think thats something RT should develop. to-compile script.r Paul Tretter

 [12/14] from: petr::krenzelok::trz::cz at: 29-Dec-2001 23:41


----- Original Message ----- From: "Paul Tretter" <[ptretter--charter--net]> To: <[rebol-list--rebol--com]> Sent: Saturday, December 29, 2001 2:52 PM Subject: [REBOL] Re: RFC: REBOL Home Multimedia Platform (RHMP)
> And to add to that: REBOL is an interpreted language, therefore the speed > that is usually required for handling the formats mentioned is not best > suited for REBOL. And encap is not a solution either as it does NOT
compile
> :( REBOL scripts. I do however think thats something RT should develop.
1) we know that Rebol is not suitable here .... it is clear it can't handle those things in the language level itself .... 2) we were talking Encap here as a kind of bridge app - listening on tcp port on one side, while talking to native OS libraries on another side ... However, for Rebol, the solution is to bring unified interface to various domain specific areas. Do you see how encryption and sound ports are handled? - native engines, providing access thru port mechanism .... I think upcoming 3D (taken from the OSNews interview with Carl) will be imo some kind of configurable port too ... ... as for compiler itself, - few rebol gurus already stated it is not possible in an effective manner, IIRC .... -pekr-

 [13/14] from: robert:muench:robertmuench at: 30-Dec-2001 12:54


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 5>>
> domain specific areas. Do you see how encryption and sound ports are > handled? - native engines, providing access thru port mechanism
Hi, IMO the port pattern can be used to create a real nice interface architecture. Can you imagine building up a processing pipeline by chaining all kind of external applications and this chaining is handle by Rebol? In this case Rebol just needs to read data, transform it and send it of the next channel... that's what I want to do! And if you keep the interface and protocoll small, Rebol is more than fast enough for this :-))
> I think upcoming 3D (taken from the OSNews interview with Carl) will be imo
some
> kind of configurable port too ...
;-)) You know how OpenGL works? It has this pipeline approach and it's really clever. So just raise this concept one abstraction level and...
> ... as for compiler itself, - few rebol gurus already stated it is not > possible in an effective manner, IIRC ....
It might be possilbe but why? What do you get? If I need speed, I fire up my C++ compiler and just write the couple of functions needed. The dynamic feature of Rebol is what makes it so nice to use and that's the difference to a static compiled-once file... Therefore I want to use both, each on the part it was made for. Robert

 [14/14] from: robert:muench:robertmuench at: 30-Dec-2001 12:54


> -----Original Message----- > From: [rebol-bounce--rebol--com] [mailto:[rebol-bounce--rebol--com]]On Behalf Of
<<quoted lines omitted: 4>>
> img: load %coins.jpg > parse img [img-ptr:] ; a cool "hack" :-)
Hi, that's working... cool! I think I have to dump such an 'img to see what's all contained in it :-)). Nice thing.
> it is fast - very fast. I can't imagine doing pick/poke upon each pixel > of image on a larger image.
Yes right, Rebol isn't made for such things. A cool thing would be to have an compile-on-demand dialect where you can write such direct face manipulation code and get it compiled into assembler code for your platform. As you can see from the C source, you only need to get your hands at the pointer, the rest is quite easy.
> General convolution mechanism is not accessible from Rebol level.
Convolution? What's that?
> The question is - if you would like to create e.g. some fire effect > (having face with some 20/sec fps timer set) how vital would be such > often library access ...
Not at all. You would have to code your fire effect completly with C and just trigger it once with some parameters from Rebol and than let it run.
> so you are skilled enough to create small listening server in C code?
Yeah, no problem.
> Now I understand your intentions ..... it would be interesting to hear > RTs plans for such area though ...
:-)) I'm currently wirting a first draft of my idea and will publish it on my website. There I want to collect all information, which than can be used to start the coding. My first thing I want to do is MP3 playback. Shouldn't be a big deal. My favorite MP3 decoder library is MAD, it's integer only and sounds great! I went to get the DigitalMars C++ compiler... just need to write some scripts for building makefiles ;-)) It's a first shot but we will see. Robert

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted