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