Car-PC.info :: Thema anzeigen - Die Zukunft von cPOS

Car-PC.info

cPOS - Die Zukunft von cPOS

vbherodes - So 27 Aug, 2006 19:48
Titel: Die Zukunft von cPOS

<Laienmode>
Eine Vision einer gesplitteten Version könnte so aussehen:

CORE:
- Standardaufgaben
- laden von Plug-Ins
-

MP:
- abspielen von Mediendateien / Streams
- wahlweise einbinden von Winamp oder Mediaplayer

PHONE:
- Verbindung zum Telefon handlen
- Kontaktverwaltung
-

DB:
- Datenverwaltung
- evtl. Datenbank für Mediendateien (schnelle Suche über den Bestand nach mp3 Tag Kriterien)

VIS:
- Steuerung der Anzeige
- Ausgabe des Programms (Skins usw)
- Steuerung wo Videos wiedergegeben werden (Multimonitorung)
-

SOUND:
- Steuerung der Soundausgabe (was wohin in welches Laustärke)
-

EH:
- evtl ein eigener Thread um CPOS zu entlasten
- Events verarbeiten, auslösen, use
-

ODB:
- wie der Name schon sagt
-

EXTAPP:
- Externe Anwendungen starten/beenden usw.
-

IO:
- Anbindung von exterenen Datenquellen (IO Karten)

CAMS:
- Webcams verwalten

es fehlen sicherlich noch Module, aber so in der Art könnte das schon hingehen.

Dann wäre es jedenfalls machbar, dass die VIS Jungs sichnicht mit den PHONE Jungs in die Quere kommen. Weiterhin könnten sich die Spezis je ein Gebiet krallen und OPTIMAL ausarbeiten.

MfG
Marc
</Laienmode>

vbherodes - So 27 Aug, 2006 20:14
Titel:

Hi Sir,

manchmal sind wir mehr Entwickler als man von sich selbst denkt (nimm es einfach so hin Smile

)))) ).
Du kennst das ja sicherlich, man muss manchmal nur eine Diskussionsgrundlage einbringen, dann wird daran gefeilt und irgendwann wirs evtl. gut.

Wenn ich mir mehr Zeit antun würde, dann würde ich auch gerne irgendwie mitentwickeln / umsetzen.

Mein Problem ist, dass ich für meine Firma C++ lernen muss und ich habe die befürchtung, dass ich mit VB zu verwöhnt werden Smile

).

Ich weis nicht recht, ob ich wirklich beides machen soll.

Ideen gehen mir eigentlich nie aus Smile

)

Aber nun wieder zu ernsthafterem.
Ein Vergleich von verschiedenen Quelltextverwaltungssystemen kann man hier finden:
http://better-scm.berlios.de/comparison/comparison.html

Vielleicht hilft das bei der Suche nach einem geeigneten Tool.

MfG
Marc

naruto - So 27 Aug, 2006 21:55
Titel:

Hi,

das mit dem splitten ist ne super Idee Very Happy

allerdings ist das Problem mit dem Splitten eigentlich die grundstruktur, es würde bedeuten ein komplett neues Cpos zu Programmieren von Anfang an wo in "richtigen Modulen" (DLLs) gearbeit würde.
Dazu braucht man eigentlich auch noch die Kommunikations schnittstelle usw... also von Grundauf Sad

vbherodes - Do 31 Aug, 2006 18:39
Titel:

Okay, dann sollten wir die Aufteilung erst mal näher besprechen und evtl im WIKI im Entwicklerbereich festhalten. dann kann man weiter sehen.

Ich habe im WIKI auf der Diskussionsseite schon mal losgelegt.

MfG
Marc

BTW: Kann man Entwickler sein ohne Programmierer zu sein?

vbherodes - Mo 18 Sep, 2006 19:58
Titel:

So Jungs,
ich bin ein Stück weiter .....
ein ganz schönes Stück. Einige Haare musste ich lassen, ABER ...
... es tut sich noch nicht viel.
Was die cPOS.NET Version bisher schon kann:

- cpos.INI File öffnen und werte daraus lesen
- Skinfile öffnen und einlesen
- frMain anziegen mit Hintergrund
- ButtonEx auf vb.net umgebaut
- ein Array aus Buttons, Listview, Textboxen, PictureBoxen und diversen anderen Objekten erstellen (das muss man leider nun von Hand managen! Leider gibt es keine ControlArray's mehr)
- Es wird versucht Buttons zu zeichnen, das funktioniert soweit, bis auf das wesentliche, DAS BILD des Buttons mag noch nicht.

Das alles war 1 Woche Arbeit für mich.
Nun würe ich die "Diskussionsgrundlage" gerne mal Online stellen, vielleicht möchte der ein oder andere weiter dran basteln. Ich werde das jedenfalls tun!

Ein Paar neue Ideen könnten evtl. jetzt schon einfließen.

Ich bräucht noch Hilfe beim kompletten umsetzend er ButtonEx Klasse, da sie ja noch keine Bilder mag!

MfG
Marc

SirGroovy2004 - Mo 18 Sep, 2006 20:01
Titel:

Servus vbherodes,

wie jetz? Was jetz? Warum jetz? cPos.net???? Ganz klar.. ich werd´ alt. VBherodes du bist ja der Hammer. Ich bin ja mal gespannt, wie der Naruto das aufnimmt. Smile

CU

SirGroovy2004

Dirk - Mo 18 Sep, 2006 20:07
Titel:

vbherodes hat folgendes geschrieben:

Nun würe ich die "Diskussionsgrundlage" gerne mal Online stellen, vielleicht möchte der ein oder andere weiter dran basteln. Ich werde das jedenfalls tun!

You got Mail

(hab auch irgendwie gepennt, denn hab da auch nix von mitbekommen) nun wirds aber wirklich Zeit für ein management system Smile

)

SirGroovy2004 - Di 19 Sep, 2006 07:39
Titel:

Servus Dirk,
Servus vbherodes,
Servus Naruto,

ich sehe da ein Problem aufziehen. VBherodes schreibt an cPos.net und Naruto an cPos 1.0, welches wohl noch auf VB6 basieren wird.

CU

SirGroovy2004

Dirk - Di 19 Sep, 2006 10:04
Titel:

Jain,

ich würde dass nicht unbedingt als Problem sehen, wenn es eine Version 1.0 gibt (stabil, schnell, etc ...) an der dann vieleicht erstmal "nur" bugfixing betrieben wird.
Und eine Entwicklungsumgebung, in der an .NET gearbeitet wird (nach den ganzen Diskussionen schaut dass nach dem zukunftssicherstem Design aus, da es schon modular ist und somit auch viele drann arbeiten können)
Diese Version würde dann nach und nach auf Stand 1.0 gebracht (alle Funktionen übernommen, schnell, stabil ...) und ersetzt dann die VB6 1.0. Dass wäre, nach meinem (nciht developer Verständniss) ein gigantischer Schritt, zum weiterarbeiten im Open source Bereich (ich lasse mich da aber auch eines besseren belehren wenn dem so ist)

bei der Portierung auf eine Neue Plattform, müsste / würde erstmal eine Parallele Entwicklung stattfinden, dass ist klar. Denn wenn du plötzlich von heute auf morgen die eine Schiene einstellst, und n halbes Jahr oder Jahr nix mehr passiert, verlierst du ziemlich schnell user.

billy - Di 19 Sep, 2006 10:56
Titel:

also .Net portierung wäre nicht schlecht, dann könnte ich auch in die programmierung mit einsteigen.

gruß
billy

Wal - Di 19 Sep, 2006 13:55
Titel:

Da könnt ihr alles unter 2 GHz vergessen, hatte mal angefangen und das ist sowas von lahm. Der Geschwindigkeitsverlust kommt durch die Transparenz der Button's, habe ich beim testen festgestellt.
Skinaufbau bei einem 2,4 GHz Pentium4 Notebook ca. 3sec, auf einem Epia ?
Der Rest ist von der Geschwindigkeit gleich. Eine Möglichkeit wäre noch alle Menu's beim Start zu laden und danach nur noch die Form in den Vordergrund zu bringen.
@vbherodes,
kannst du das bestätigen oder läuft es bei dir bei der Umschaltung flüssig.
ControlArrays gibt es natürlich noch. Ich kann dir ja meine Version mal zusenden.Skin's gehen ohne änderung einzulesen und die Button's(bei mir Picturebox) auszuwerten. Sonst geht noch nicht's, da ich wegen dem Speed danach abgebrochen habe.
Z.Z. schaue ich mir Turbo Delphi an, da es jetzt kostenlos bei Borland gibt.
Wal

rytox - Di 19 Sep, 2006 16:09
Titel:

alter schwede, das war auch mein gedanke als ich die letzten paar posts las.. cpos.net? viel spaß bei epias o.ä..

war in letzter zeit sehr ruhig, hab aber leider viel um die ohren, unfall gehabt und und und..

trotzdem bin ich noch an cpos dran. meine nokia 6230 version läuft. ohne probleme.. dass ich da sowenig feedback bekommen hatte wundert mich sowieso. egal.
wireless ist soweit integriert, dass momentane SSID und signalstärke in cpos angezeigt werden können. veröffentlicht wirds aber vorerst noch nicht.

trotzdem.. bitte überlegt euch gut, was ihr da mit .net vorhabt..

Dirk - Di 19 Sep, 2006 16:17
Titel:

macht .NET dass wirklich so Rechenlastig? oder wo genau besteht da dass Problem? soweit ich dass bisher verstanden habe, ist dass im Prinzip doch dass selbe, nur dass eben eine andere Sprache verwendet wird. oder?

(VB, welche nimmst du C++?) in der sind doch die meisten Programme heute geschrieben, auch mit Grafischer Oberfläche, und da gibt es doch eher wenige Probleme.

Ist .NET nicht eine Voraussetzung für ein vernünftiges aufsplitten in Module gewesen?

vbherodes - Di 19 Sep, 2006 19:41
Titel:

Hallo Wal, gerne kannst du mir deine Verison mal zukommen lassen.

Warum sollten wir wegen ein PAar Sekunden, von mir aus 5, beim Start entscheiden nicht vb.Net zu nehmen?
Ich denke es gibt aber auch noch andere Punkt für eine Perfromanceverbesserung beim Start.
BTW ich hab noch keine Release Veriosn gebaut. Immer nur Debug und das sollte beim Release ja nochwas gehen.
Eine Idee ist die INI Datei z.B. komplett auf einen Rutsch einzulesen und dann dei Werte aus dem Speicher zu holen, statt immer "GetPrivateWhatever" zu belämmern. Ich kann mir nicht vorstellen, dass das zwingend förderlich ist.

Ich denke dass .NET keine Bremse sein muss...
Zumal wir dann ein Stück näher am "alten Stand" sind als mit Delphi.

@Dirk:

Die Module sind schon ganz gut gesplittet.

Wal - Di 19 Sep, 2006 19:51
Titel:

Schick mir mal deine E-Mail-Adresse über PN.
Die 3 sec. sind zwischen den Menü's, nicht beim starten. Ist also nervend.
Ich kann mir nicht vorstellen eine bedienbare Version für Epia mit .net zu erstellen, laß mich aber gerne überraschen.Du wirst zwischen Debug und Release keinen Geschwindigkeitsunterschied feststellen können.
Habe mir zwar ein VB.Net Buch gekauft, bin aber von dem Speed der Sprache total enttäuscht. Da ist VB um längen schneller.

@Dirk,
C++ ja, aber nicht .net

Wal

fuchs - Di 19 Sep, 2006 22:05
Titel:

Hi,

die wartezeit beim menüwechsel kommt hauptsächlich durch das entpacken der jpg-grafiken.
das kann man eigentlich nur bescheunigen, wenn man den skinaufbau auf das system von roadrunner umbaut, also weg von den vielen kleinen grafiken, hin zu 3 hintergrundbildern, die die over und down bilder der buttons enthalten.
das "GetPrivateWhatever" dauert nicht lange, weil die ini datei nach dem ersten aufruf eh im cache steht.

gruß,
fuchs

LEDproject - Di 19 Sep, 2006 23:13
Titel:

Hallo,

Will auch mal noch meinen Senf dazugeben Smile

..

Ich bin ebenfalls der Meinung dass sich das Umsteigen auf .net lohnen würde.
Ich nehme jetzt mal an, ihr sprecht alle von vb.net?
Wär es nicht gescheiter das ganze direkt mit c# zu entwickeln? denn um .net richtig nutzen zu können ist c# dem vb.net klar vorzuziehen...
Was haltet ihr davon?

gruss

Wal - Mi 20 Sep, 2006 00:55
Titel:

@LEDproject,
es gibt nicht's was du mit c# machen kannst, was in vb.net nicht gehen würde und hat auch kein Geschwindigkeitsvorteil. Ist nur eine Glaubensfrage.
@Fuchs,
liegt leider nicht an jpg.
Wenn ich die Transparenz der Button's einschalte, kann man beim verstecken der Button's (Button.visible = False) mit zuschauen wie einer nach dem anderen von der Form verschwindet.Schalte ich die Transparenz ab, dauert der Aufbau nur noch ca. 1/3 der Zeit.

Wal

naruto - Mi 20 Sep, 2006 09:34
Titel:

Zu der 1.0 es soll so sein wie der Dirk geschrieben hat, habe das mit WAL schon besprochen wir wollen eine 1.0 rausbringen, wo es dann nur noch Bugfixes geben soll und keine neuen Funktionen.
Danach versuchen wir cPOS komplett neu aufzuziehen in modularer Bauweise aber mal schauen wie das Laufen soll.

@rytox
ich habe deine änderung ja in die 500.xx eingebaut läuft bis auf das auflegen ganz gut was ich so gelesen habe Smile

Sag mal bitte mehr zu dem WLAN zeug.

CU

SirGroovy2004 - Mi 20 Sep, 2006 10:58
Titel:

Na, dann hamma hier bis auf´s Glühwürmchen ja die GANZE "Promminenz" versammelt. Smile

Schöne Diskussion hier...

Wal - Mi 20 Sep, 2006 11:43
Titel:

Die neue cPOS-Version wird auf jeden Fall auf FMOD aufbauen.
DSP,Equalizer,mehrere Soundkarten u.s.w wird unterstützt.
Die Programmiersprache steht noch nicht fest, wird aber eine kostenlos erhältliche sein, damit jeder seinen Senf mit einprogrammieren könnte.
Das sind zu Zeit :
Visual Basic Net
Visual C#
Visual C++ Net
Turbo Delphi Eplorer
Turbo Delphi Net Eplorer
Turbo C# Explorer
Turbo C++ Eplorer
Ich tendiere zu Turbo Delphi Explorer, ist ohne net und man kann damit auch dll's programmieren. Die Umgewöhnung von Visual Basic ist nicht so schwer.

Wal

Dirk - Mi 20 Sep, 2006 12:18
Titel:

Hups, dass nenn ich mal ne Nette Engine Smile

kannte ich noch garnicht. da bin ich jetzt schon ganz heiß drauf :)

Wal und restlichen Entwickler, was braucht ihr für ne Plattform?
Ich kann zwar nciht beim Programmieren helfen, aber vieleicht mit der Infrastruktur.
(bin ernsthaft am überlegen mir nen RootServer zu besorgen, und wenns nur ein Virtueller ist)

da wäre zuerstm mal n Versionsmanagement, was sonst?

allerdings den wirds nicht vor Oktober geben Smile

fuchs - Mi 20 Sep, 2006 18:05
Titel:

@wal:
die aussage über das zeitintensive entpacken der jpg grafiken bezog sich noch auf die jetzige cpos version in vb6.

dieses fmod gefällt mir sehr gut. Da es sich hier ja um ein Freeware Projekt ohne irgendwelche kommerziellen interessen handelt, kann man es sogar kostenlos nutzen. super!

hast du zufällig für die videowiedergabe auch schon so ein schönes tool gefunden?

in den kostenlosen borland turbo versionen kann man leider keine externe komponenten verwenden (also z.b. das skinbare button-objekt). das könnte evtl. irgendwann zu problemen führen. (läuft fmod damit ? )

gruß,
fuchs

rytox - Mi 20 Sep, 2006 20:49
Titel:

@naruto, gerade das auflegen sollte einwandfrei funktionieren, habe da den allgemeinen at-chup ("call hang up" genommen, der sollte bei 90% aller handys funktionieren?!?)

das du die handyfunktion übernommen hattest wusste ich gar nicht?!?!
bist sicher, dass du alles restlos übernommen hast?

mit wlan bin ich immer noch am straucheln.. ssid, signalstärke (NUR des verbundenen netztes) und insgesamte ANZAHL aller verfügbaren netze geht schon..

allerdings reicht mir das nicht, mich interessiert nicht nur mit welchem netz ich verbunden bin, sondern auch obs noch andere netze in reichweite gibt..
wie gesagt da bin ich dran!

Wal - Mi 20 Sep, 2006 21:56
Titel:

@fuchs,
ja fmod habe ich schon auf Turbo Delphi angepasst und es läuft schon damit.
Als Testprojekt habe ich die Spektrumdemosource genommen und auch angepaßt.
Waren alles nur kleine Änderungen. Habe vor Jahren mal mit Pascal geproggt und war jetzt überrascht das ich so schnell das Alles zu laufen gebracht habe.
Das mit den Komponenten ist schon wahr, aber kein Problem, da man ja eigene direkt als Unit mit einbinden kann Razz

. Für Video habe ich noch nicht's. Wenn einer einen Vorschlag hat mit Demosources, her damit.
Habe heute mit VB.net weiter geproggt und den kompletten Skin auf dynamische Form's gebannt. Sieht mit dem überblendeten Splashscreen beim Menuwechsel jetzt ganz gut aus und von der Geschwindigkeit ist es akzeptabel. Man hat aber trotzdem das Gefühl, das es sich wie Kaugummi zieht. Müßte mal einer auf einem Epia testen.

Wal

SirGroovy2004 - Do 21 Sep, 2006 07:35
Titel:

Servus Wal,

verstehe ich das richtig? Bei jedem Menüwechsel wird cPos.net "verdunkelt" und "Menu is loading..." wird eingeblendet? Hmmm.... Wie lange dauert es denn bis cPos wieder "normal" wird? Die Besagten 4 bis 5 Sekunden?

@all

wenn ihr wirklich darüber nachdenkt, cPos von Grund auf in neuer Programmiersprache zu schreiben, dann überdenkt bitte auch gleichzeitig die Anbindung an den WMP.

CU

SirGroovy2004

Dirk - Do 21 Sep, 2006 08:46
Titel:

@ sir, WLKIKIV Very Happy

wenn ich dass nun richtig sehe (und dafür spricht Wals aussage, wird zukünftig FMOD als Audioplayer verwendet. Video ist noch keine Entscheidung gefallen (richtig?)

@ Wal, lass mir Ende nächster Woche die .NET mal zukommen, dann teste ich dass auf dem Epia.

Wal - Do 21 Sep, 2006 11:06
Titel:

@Dirk,
schick mir gerade mal deine E-Mail-Adresse über PN.

@SirGroovy2004,
habe doch jetzt den kompletten Skin auf dynamische Forms gebannt. Starten von cPOS.net dauert jetzt ca. 20 sec und der Menuwechsel ca.1 - 1,5 sec.
Die Menu's werden eingeblendet, d.h. "Menu is loading..." wird immer transparenter bis es nicht mehr zu sehen ist, aber wie gesagt dauert nur 1 - 1,5 sec. auf einem P4 2,4 GHz.

Wal

SirGroovy2004 - Do 21 Sep, 2006 11:37
Titel:

@ wal

danke für die Antwort.

@ Dirk

selber WLKIKIV !!! *schmoll*

Dirk - Do 21 Sep, 2006 11:39
Titel:

Wal - Do 21 Sep, 2006 22:26
Titel:

Ich habe mir die Mühe gemacht und das Spectrumdemo von FMOD auf verschiedene Sprachen übersetzt. Die Bilder sagen alles.

Wal

Wal - Do 21 Sep, 2006 22:31
Titel:

gelöscht :

Viper_BB9 - Do 21 Sep, 2006 22:32
Titel:

na da hat delphi aber mal sowas von klar die nase vorn... viel weniger speicher aber stimmt die cpu-last? 0% zu ca. 40%???

Wal - Do 21 Sep, 2006 22:34
Titel:

Ja stimmt auf einem P4 2,4GHz,
VB und Delphi 0-1%
c# und VB.Net 15-50%
Selber testen !!!
Beide Dateien herunterladen und in einen Ordner.Anhang konnt nicht größer als 512kb sein.

Wal

Viper_BB9 - Do 21 Sep, 2006 22:48
Titel:

so habe selber getestet auf meinem notebook mit 3ghz cpu waren alle in der prozessorlast unter 1%
merkwürdigerweise zeigte der prozess explorer bei c# und vb.net zeitweise sogar garnichts an (kleinste anzeige 0.25%)??? also liefen diese programme bei mir sogar schneller.
kann es sein das die grafikkarte auch entscheidend ist (wegen spectrometer?)

Wal - Fr 22 Sep, 2006 01:58
Titel:

@Viper_BB9,
das hätte ich jetzt nicht gedacht Embarassed

, da muß ich ja direkt noch mal auf einem anderen PC testen. Razz

Wal

Dirk - Fr 22 Sep, 2006 11:41
Titel:

Wal, wenn du größere Sachen hast, du hast doch den login zum FTP, da kannst alles draufpacken, was mit cPOS Entwicklung zu tun hat (solange du nciht gerade ein GB draufschmeißt Smile

) und hier dementsprechend verlinken.

Home PC:

Athlon XP 2400+ 1GB Ram, und GF4 4800SE WinXP Pro (aktuelle updates drauf) als Lied: TNT Very Happy

:
Delphi: ~0-2% ~11.700K (sofort gestartet)
c#: ~0-2% ~17.00K (ca 2s Verzug bis gestartet)
VB: ~0-3% ~10.300K (sofort gestartet)
VB.Net: ~0-5% ~18.000K (sofort gestartet)

CPC:

Epia MII 10000 1GHz 512MB onboard Graka (kann es sein dass externe Grakas verdammt viel Last abfangen?)
so, nun wirds bitter:
Delphi: 100%
c# kann nicht gestartet werdenn, keine ahnung warum
VB: 49-53%
VB.Net kann nicht gestartet werdenn

SirGroovy2004 - Fr 22 Sep, 2006 11:46
Titel:

Servus Wal,

interessieren dich Tests deiner drei Beispiele im allgemeinden? Sprich: Soll ich dir auch schreiben, was mein Laptop und/oder mein Carpc für Komponenten hat und wie die CPU Auslastund da ist?

Recht herzlichen Dank für die Aufmerksamkeit.

SirGroovy2004

divemarc - Fr 22 Sep, 2006 13:38
Titel:

Jungs, bei aller Euphorie achtet bitte darauf, dass hier keine Zweiklassengesellschaft entsteht.
Viele viele User hier im Forum haben epia-Boards im Einsatz und die haben leider nur 1GHz!!!
Fände es sehr schade, wenn es irgendwann heisst "Eure (GHz-) Armut kotzt mich an ;o)
Wer bitte steht hinter einer Software, wenn ein Menuwechsel zwischen 3 und 8 Sekunden dauert?
Auf meinem Epia ist das jetzt schon der Fall!
Andere Programme wie z.B. Navigon schalten in Sekundenbruchteilen um.

Dirk - Fr 22 Sep, 2006 14:02
Titel:

darum ist hier ja noch die Diskussion im Gange Smile

dass eben auch mal die ersten Versionen (geht hier ja hauptsächlich um die Frage der Programmiersprach in den letzten Beiträgen) in den möglichen Sprachen getestet werden. wie CPU-Lastig, wie flink auch auf schwachen systemen ... und ob es dann gleich wieder rausfliegt aus der Wahl. denn eine CarPC Software, die nciht auf nem Epia läuft, ist denke ich nciht tragbar, dazu verwenden zu viele die Epias. (und dass sind nunmal die schwächsten Systeme) Ich weis wovon ich rede, ich hab selbst n Epia :)

PS: ich war mal so frei, und hab diese Diskussion von der Entwicklerplattform abgesplittet, da es ja nimmer um die Plattform selbst geht, sondern schon um das weitere Vorgehen von cPOS selbst. Einwände?

tow-b.de - Fr 22 Sep, 2006 14:16
Titel:

Zitat:

auf nem Athlon XP 2400+ 1GB Ram, und GF4 4800SE WinXP Pro (aktuelle updates drauf) als Lied: TNT :
Delphi: ~0-2% ~11.700K (sofort gestartet)
c#: ~0-2% ~17.00K (ca 2s Verzug bis gestartet)
VB: ~0-3% ~10.300K (sofort gestartet)
VB.Net: ~0-5% ~18.000K (sofort gestartet)

irgendwie kommt mir das ein bischen merkwürdig vor, eigentlich müssten C# und VB.NET ca glleich schnell laufen und gleich viel Speicher belegen.
Hattest du das in der Reihenfolge getestet? Weil die CLR muss für die .NET-Anwendungen einmalig starten (das könnte die 2 Sek erklären).

Grundsätzlich wär ich dafür es Richtung .NET zu bringen, alleine schon weil bei einem modularen Aufbau alle Plug-Ins in verschiedenen Sprachen geschrieben werden können. Dazu muss aber natürlich der Speed passen und gerade bei epias sehe ich da schon ziemlich schwarz.. Sogar mein kleines SubNotebook mit PIIIm 1,2 hat da ja schon mehr Power..

@Wal: könntest du mir vielleicht mal den Quelltext der .NET Version zur Verfügung stellen? Ich programmierte Jahrelang C++ und momentan C#, VB musste ich zwischendurch natürlich des öfteren auch mal in manchen Projekten bemühen.
Würde mir das gerne mal ansehen und vllt. kommen mir ja auch noch ein paar Ideen, ob man irgendwie, irgendwo was am Speed machen kann. Vllt auch was grundsätzliches, was sich nicht soo schwer umsetzen ließe. Bin halt noch nicht im Code drin und habe vllt. nen etwas anderen Blickwinkel darauf..

Dirk - Fr 22 Sep, 2006 14:21
Titel:

ja, in der Reihenfolge hab ichs gestartet.

Wal - Fr 22 Sep, 2006 16:01
Titel:

@tow-b.de,
das waren jetzt nur Demosources die bei dem FMOD-Project dabei waren, bis auf VB.Net, da mußte ich Hand anlegen.
Du kannst dir's ja mal herunterladen.Hier.
Das Demo hat den Namen "Spectrum". Die FOD-Version: FMOD Ex 4.04.28 (STABLE)

@Dirk,
du wirst auf deinem Epia kein Net.Framework installiert haben oder die 1.1, deshalb werden die .Net Programme nicht laufen.

Wal

tow-b.de - Fr 22 Sep, 2006 16:35
Titel:

Achsoo, ich hatte das in dem anderen (langen Thread) so verstanden, das du das cPOS teilweise portiert hattest (mit dem Menüwechsel-Fading weils 1-2Sek dauert.. etc.)...

So habe mir die Sources mal geladen.. auf meinem PC laufen die relativ fix, was aber auch kein Wunder ist (Athlon64), 5-11% CPU, 12,5MB + Soundfile (das er scheinbar sofort komplett reinlädt).. Dann kommen noch 5MB für die CLI dazu.. Ist aber schon relativ happig - liegt aber schätzungsweise nicht alleine am .NET - ohne die DLLs und nem normalen Loop mit Randomizer um das GDI fürs Spectrometer nachzuahmen ist so gut wie keine Belastung festzustellen (ausser natürlich die 5MB der CLI).. Und das ganze Ding ist ohne DoubleBuffer programmiert - nejnej Very Happy

Mein Notebook teste ich evlt heute auch nochmal - da ist nur just vorhin die Platte abgeschissen nachdem die schon wochenlang gequitscht hatte, hab aber schon ne neue eingebaut und installiere grad Win Smile

Mal ganz ne andere Idee, kann man in eine Anwendung die nativ kompiliert ist, auch Plugins laden, welche auf .NET basieren? Anders herum klappt es ja auch.. fmodex.dll und fmodexp.dll sind ja auch nativ für Win32 kompiliert..

nochmal edit: So, das Notebook rennt jetzt auch wieder.. da fällt jetzt auf, das die GDI echt grottig programmiert ist Smile

Ich habe bisher nur Treiber + .NET Framework installiert. Wenn ich mir das gesamte Spectro anzeigen lasse, habe ich 100% Auslastung! egal ob nen lied läuft oder nicht.. verdecke ich das Fenster komplett (während die Musik läuft) fällt die Belastung auf 1% ab. Leistungsfressend ist die linke Darstellung, muss die nach der Paint-Nachricht neu gezeichnet werden, bricht die Leistung total ein. Ist der Bereich mit den grünen Balken verdeckt und nur das weisse spectro zu sehen, dann hab ich höchstens mal kurz 5% ansonsten immer 1% CPU-Last.. Grafikchip ist übrigens ein Intel 855 - hoffentlich etwas vergleichbar mit den VIA-Onboard-Lösungen...

Wal - Sa 23 Sep, 2006 05:06
Titel:

Die cPOS-Portierung kan ich dir auch mal senden, ist aber nur 0815 geproggt.
Das Spectrum habe ich jetzt auf einem Centrino 1,6 GHz getestet mit vb.net und habe die gleichen Symtome wie du aber ca. 40% Last. Programmiere ich die Waveform raus,also die rechte Seite Razz

habe ich nur noch 0-2% Last.
Wie Dirk auf seine Werte kommt ist mir noch ein Rätsel.
Fazit:Grafik und .Net wollen anscheinend nicht. Ich muß mal SDL oder eine andere Grafikerweiterung testen.

Wal

ncc1701a - Sa 23 Sep, 2006 06:10
Titel: .net und CPU Last

Bisher ist mir aufgefallen, dass .net / mono Anwendungen echte CPU Schweine sind. Eine CarPC Lösung auf .net Basis habe ich daher auch wieder entfernt.
Selbst bei der aktuellen cpos Version ist der Unterschied zwischen Intel Core Duo und einem 600er VIA EPIA Board schon sehr auffällig. Alleine der Windows XP Start, der zwar absolut nichts mit cpos zu tun hat, dauert auf dem EPIA schon ewig lang. Daher ist meine Entscheidung auch auf ein Core Duo gefallen. Das EPIA braucht etwa die 4fache Zeit für den Systemstart.
Ich weiss auch nicht ob .net für EPIA die richtige Entscheidung ist, die libqt ist da sehr viel schlanker, dafür aber auch viel schneller und unterstützt neben Windows auch Linux und FreeBSD. Qtopia wird sogar für Handies verwendet und die haben noch weniger CPU Leistung als ein EPIA Board. Das "normale" Qt verlangt unter Linux jedoch nach X11 oder eben nach Windows XP. Für Software unter GPL kann die kostenlose GPL Version von Qt(opia) verwendet werden. Da die Umstellung auf .net einen ebenso großen Schnitt für cpos bedeutet, wie der Umstieg auf Qt, wäre meine Bitte, dass Ihr Euch das auch einmal überlegt. Ich möchte hier auch zu bedenken geben, dass der Support für WindowsXP auch einmal endet und Windows Vista will wohl niemand ernsthaft auf einem EPIA Board laufen lassen.
Eine kleine Testanwendung habe ich einfach mal für das 600er EPIA Board optimiert. Die Startskripte von Linux starten nun, soweit möglich, alle gleichzeitig. Der abgespeckte Kernel selbst braucht nur ein paar Sekunden für den Start. Auch der ganze Tcp-Stack wird erst später nachgeladen, wenn er auch gebraucht wird. Die Qtopia Anwendung braucht ebenfalls nur ein paar Sekunden für den Start. Einen Nachteil der Linux-Lösung möchte ich aber auch nicht verschweigen: Es gibt bisher keine vernünftige Navilösung für Linux. Mit Wine oder Vmware und X11 ist aber auch das zu lösen, WindowsXP wird dann aber auch erst gestartet, wenn das Navisystem gebraucht wird. Schneller als TomTom6 auf einem 600MHz PDA ist es aber immer noch. Wenn Vmware erstmal läuft, dann merkt man die virtuelle Maschine praktisch nicht.
In den vorangegangenen Posts wird darauf hingewiesen, dass sehr viele cpos Installationen auf EPIA Boards laufen, diese Userbase solltet Ihr nicht einfach ignorieren. Auch meine Core Duo Lösung hat irgendwo ihre Grenzen, die werden offenbar mit .net auch schnell erreicht.

Etwas OT: Als Multimedia Ausgabeprozessor kann man mplayer verwenden, der frisst alles: Ogg, MP3, MPEG2, DivX und viele mehr. Da braucht man sich keinen Kopf mehr um fehlende Codes mehr zu machen.

Dirk - Sa 23 Sep, 2006 07:20
Titel:

Wal hat folgendes geschrieben:

Wie Dirk auf seine Werte kommt ist mir noch ein Rätsel.

Welche? die auf dem Epia oder die auf dem Home PC?

glow - Sa 23 Sep, 2006 08:14
Titel:

jetzt hau ich mich aber auch mal rein...
@ncc1701a

ein carpc ist in erster linie dazu gedacht bestehende oem multimedialösungen
günstig zu ersetzen. nicht jeder hat vor sich nen core duo oder einen pentium m reinzusetzen oder möchte bzw. kann das geld dafür ausgeben.
wenn der carcp im endeffekt teurer wird als das pioneer x1 z.b. ist das thema für die meisten erledigt. mp3 archiv, navi und ein paar sonstige spielereien - mehr braucht der großteil der user nicht.
und dafür reicht ein epia allemal.
linux fällt immernoch komplett flach ohne richtiges navi. bisher tat sich da nix und in absehbarer zukunft tut sich nix..ne windows navisoftware unter linux virtuell mit vmware oder wine laufen zu lassen - das ist wieder so ne `frickellösung`und mehr ein notwendiges provisorium unter linux,
das kann nicht sinn der sache sein.
der systemstart dauert auf nem epia nur länger, da die ganze bios routine abgearbeitet wird bevor z.b. xp startet.
sicher geht der eigentliche xp start auf leistungstärkerer hardware schneller voran, das ist aber nebensache da doch meistens eh hibernate oder standby genutzt wird.

@all
soo...nun wart ich mal weiter ab was sich hier tut Smile

.
wenns was zu skinnen gibt - bin da.
aber menuwechsel oder ein cpos start von mehreren sekunden kommen für eine carpc software die ich auf meinem carpc laufen hab nicht in frage.

Wal - Sa 23 Sep, 2006 12:03
Titel:

@Dirk,
auf dem Home-PC, bei dem alle Prog's bei dir mit 0-2% Last laufen.

@All,
hat einer mal Centrafuse auf einem Epia laufen ?
Ist ja eine .Net-Anwendung, da könnte man ja mal die Geschwindigkeit testen.

Wal

Dirk - Sa 23 Sep, 2006 14:08
Titel:

ganz einfach, ich hab die Anwendungen gestartet, jeweils das selbe lied durchlaufen lassen, und dabei den Taskmanager im Auge behalten, der ist immer zwischen den jeweiligen WErten geschwankt. darum ~0-x%

oder meinst die Angaben der Startzeit? (dass ist ne ca Angabe)

Bigdesaster - So 24 Sep, 2006 13:36
Titel:

Hi,
ich muss zugeben, daß ich Privat wenn ich Programme schreibe mittlerweile auch eher VB.Net benutze.
Aber es stimmt schon, daß die .Net sachen CPU und Speicherintensiver sind als VB6.
Ich hab beim dem Spectrum mit .Net auch ca. 40% CPU-Last. Confused

Das spricht meiner Meinung nach eher dafür auf VB6-Basis weiterzuentwickeln.

Das mit FMOD find ich ne gute Sache. Hatte vor 1 oder 2 Jahren auch schon versuche mit FMOD & VB6 gemacht.

vbherodes - Mo 25 Sep, 2006 18:51
Titel:

Können wir mal die Pro's und Con's der Programmiersprachen zusammentragen und uns dann für eine entscheiden?

VB6 - schnell, einfach zu erlernen?
VB.NET - langsam, speicherhungrig, einfach zu erlernen
C++ - schnell (??), ...
DELPHI - ??

MfG
Marc

Wal - Mo 25 Sep, 2006 20:34
Titel:

Ich würde Turbo Delphi bevorzugen, programmiere jetzt 1 Woche mit Delphi und muß sagen, es ist Kinderleicht zu lernen.
Hier das Ergebnis bis jetzt.
Ich bitte nochmal darum die CPU-Last des Programm's auf einem Epia zu testen.

Wal

Dirk - Mo 25 Sep, 2006 20:58
Titel:

kommt donnerstag mittag oder freitag vormittag.

vbherodes - Mo 25 Sep, 2006 21:12
Titel:

Beeindruckend WENIG Last.
Der Prozess verursacht nicht mal 1% auf einem Athlon 64 3000.
Die Anzeige bleibt immer bei 0%!!

MfG
Marc

billy - Mo 25 Sep, 2006 21:33
Titel:

also ich habe jetzt das fmod mal getestet:

fazit:
also das ding mit dem spectrum läuft auf meinem 1,6ghz pentium M mit unter 2% last, bei meinem Epia MII10000 mit knapp 5%.

bei beiden knapp 12000kb im arbeitsspeicher (ist kein problem bei 512mb)

gruß
billy

Bigdesaster - Di 26 Sep, 2006 04:50
Titel:

wal, da muss ein Fehler drin sein....
ich hab nämlich fast keine CPU Last *gg* Laughing

Sieht soweit jedenfalls gut aus mit dem Delphi.

Wal - Di 26 Sep, 2006 08:42
Titel:

So ein paar Spielereien hinzugefügt, damit das Epia endlich mal ausgelastet wird. Twisted Evil

Die Sourcen sind für's mitentwickeln.
Als nächstes ist ein Equalizer dran.

Wal

SirGroovy2004 - Di 26 Sep, 2006 09:07
Titel:

*g* Schönes Spielzeug...

tow-b.de - Di 26 Sep, 2006 12:38
Titel:

Ja gut, von mir aus auch Turbo-Delphi, kenn ich zwar noch nicht, aber das muss ja nicht schlimm sein, was neues zu lernen hat noch nie geschadet, und wenn man C++ kann, geht auch alles andere RuckZuck, man muss ja fast nur andere Bibliotheken lernen...

Dann überleg dir vllt. schonmal wie man das ganze Modular aufbauen kann - damit dann Schnittstellen definiert und veröffentlich werden können (schon vorm implementieren) dann dürfte auch schnell auffallen ob noch etwas fehlt, was später schwierig zu erweitern wär (ist ja immer son Problem bei Schnittstellen)..

Vllt. sollten wir in Anbetracht ziehen, Winamp-Vis-Plugins laden zu können, das wär doch ne super-sache.. Wink

Aber dazu muss ich mir erstmal Turbo-Delphi ansehen, wie es da mit dem laden von dlls etc. aussieht..
bzw, könnte man auch nen Modul programmieren, was dann die Kommunikation mit dem WinAmp-Plugin übernimmt, dann muss man nur alle Daten zur Verfügung haben..

Wal - Di 26 Sep, 2006 15:49
Titel:

@tow-b.de,
laden von Winamp und VST Plugin's ist mit FMOD kein Problem, ist schon drin.
Ich jabe auch erst vor 1 Woche mit Turbo Delphi angefangen, da kann keiner sagen ich hab keine Ahnung sondern einfach mal loslegen.

@All,
jetzt mit EQ, da glüht das Epia. Laughing

Wal

P.S. Turbo Delphi Explorer Download
Lizenzschlüssel-Download
Hier Registrieren.

billy - Di 26 Sep, 2006 15:59
Titel:

jaja glühen, bei 6,3% system last

gruß
billy

Wal - Di 26 Sep, 2006 16:04
Titel:

@Billy,
die Systemlast beträgt 5,74%.
Du mußt ja auch den EQ und ein paar DSP's einschalten, danach wird's erst warm. Razz

Wal

billy - Di 26 Sep, 2006 16:22
Titel:

also mit fast allen aktiven DSP´s sind es dann schon fast 60% mehr aber nicht auch mit dem Equilazer nicht.

kannst du mir die ini vom frosch skin schicken, wegen einbindung der RC 10 in den MCE skin.

gruß
billy

Wal - Di 26 Sep, 2006 16:42
Titel:

Bitte schön.
Du hast ja auch ein Centrino sehe ich gerade und kein Epia.

Wal

tow-b.de - Di 26 Sep, 2006 18:03
Titel:

Ich lad's grad mal runter.. und dann ma schaue watt so geht Wink

billy - Di 26 Sep, 2006 18:10
Titel:

ja hatte davor aber ein MII10000 und das läuft daheim noch mit zum verschiedenste kombinationen von software zu testen.

gruß
billy

billy - Di 26 Sep, 2006 18:13
Titel:

ah, jetzt steige ich so langsam bei der bedienung mit der RC 10 durch

gruß
billy

EricB - Mi 27 Sep, 2006 23:42
Titel:

Es gab mal die Frage bzgl. Video - Habt ihr euch das schon angesehen:

http://www.mplayerhq.hu/design7/news.html

Ciao

x3on - Fr 29 Sep, 2006 02:20
Titel:

Hmm, Turbo-Delphi hört sich schon irgendwie gut an.

Aber wenn cPOS neu aufgebaut werden soll, dann wärs toll, wenn man gleich die anderen Beschränkungen auch aufheben würde ... z.B. mit nem offenen Interface für den Media-Player.
So können die Leute die den WMP bevorzugen weiter den benutzen, für die anderen gibts Winamp und für mich dann foobar2000 *g*

Vielleicht gefällt foobar auch noch jemandem anders: http://www.foobar2000.org/

Vorteile: Extrem schnell, kann nativ schon sehr viele Formate wiedergeben, hat ne offene Programmierschnittstelle und vor allem: Kann cue-sheets wiedergeben (und das ist eine wirklich geile Funktion).

Und mplayer als Video-Player find ich auch ne geniale Idee. Aber wie gesagt, das Beste wäre auch hier dann ne offene Schnittstelle (ich will unbedingt foobar und ned eine eigene Car-PC Software programmieren müssen, weil ja cPOS sonst recht genial ist *g*)

Und nochmal zu den Programmiersprachen: Vielleicht lässt sich schon in .NET Programmieren, wenn halt für EPIAs gleich gewisse CPU-Spar-Funktionien von Anfang an vorgesehen werden. Und vor allem wenn es Modular aufgebaut wird. Wenn ein EPIA-User nur noch die Module lädt, die er nutzt, dann reicht wahrscheinlich die Performance von seinem Recher auch für ein cPOS in .NET
Der Vorteil ist halt, dass die Programmierer-Community gleich wesentlich größer ist, da man mit allem mitprogrammieren kann.

Wal - Fr 29 Sep, 2006 06:34
Titel:

Modularer Aufbau bringt in der Geschwindigkeit nicht's, wurde schon öfter's angesprochen. Es hat andere Vorteile.

Wal

tow-b.de - Sa 30 Sep, 2006 23:12
Titel:

und verschiedene Mediaplayer kannst du nicht einbinden - wie stellst du dir das vor? Du kannst ja nicht so einfach ein Programm nehmen und das benutzen, damit das wirklich gut zu benutzen ist braucht es ne API auf die man aus cPOS direkt zugreifen kann. Das man dann nur noch die entsprechenden DLLs benötigt und das Ding rennt.

Vom Grundaufbau würde ich evtl. so rangehen, ein Framework zu bauen was alle Module verwaltet und dann wirklich so gut es geht alles in Module verpacken.
Jedes Modul hat dann eine Funktion aus der sich das Framework die Paramter für einen Eventhandler holt und diese dann wieder global managed.
Ich finde eine der genialsten Dinge am cPOS ist, das man wirklich von überall im Skin, alle Event auslösen kann und nicht an vorgaben wie "Mediaplayer", "Phone-Menü" etc gebunden ist.
Das sollte imho eines der wichtigstens Features vom Grund-CPOS werden, weil gerade das, cPOS von vielen anderen Front-Ends abhebt..

Was nun genau wie implementiert wird ist natürlich dir überlassen Wal, und wenn eine Entscheidung getroffen ist und Schnittstellen definiert sind, dann helfe ich gerne mit das eine oder andere Modul zu bauen oder zu warten/verbessern.

edit: Es könnte natürlich (wenn wirklich alles modular gebaut wird) zwei Mediaplayer-Module geben, zum Beispiel einen auf Basis von fmod und einen auf Basis des WMP oder was auch immer... das Modul stellt ja die Funktion zur Verfügung, wie es diese im Endeffekt realisiert ist die Sache des Modul. Ob dann natürlich jemand die Muße hat noch ein zweites Modul zu bauen, wenn wir ein funktionierendes haben, wage ich aber mal zu bezweifeln - aber das ist alles nur Spekulation Wink

x3on - So 01 Okt, 2006 01:53
Titel:

Hmm, gut, ok, dachte bisher foobar2000 sei open source, aber da hab ich wohl falsch gedacht Wink

aber zumindest per kommandozeile könnte man es steuern ... was wohl eine ziemlich puristische implementierung geben würde Wink

aber vielleicht gibt ja der author ne schnittstelle frei, wenn man ihn mal drauf anspricht, was wir vor hätten.
den media-player als austauschbares modul fänd ich auf jeden fall klasse.

sorry, wenn ich die frage jetzt nochmal stelle: ist .net jetzt wirklich so langsam? ich fänd es halt deswegen klasse, weil man dann wirklich viele leute hätte, die was für cpos programmieren könnten und ned nur einen geschlossenen kreis, der genau die eine programmiersprache beherrscht ...

tow-b.de - So 01 Okt, 2006 13:06
Titel:

Die Foobar-Funktion mit den Cue-Sheets ist echt klasse Wink

Das Plugin, welches es für Winamp gibt taugt dagegen nicht viel. Vor allem wenn man viele Compilations hat die gemixt sind, und dann nur aus einer MP3 bestehen..

@wal: hast du .NET schonmal mit der TAO-Library probiert? Da könnte man die Grafik dann relativ einfach über DirectDraw laufen lassen. Das sollte erheblich performanter als GDI sein, und das unterstützen doch auch die Epia-Boards, oder?

Dirk - So 01 Okt, 2006 13:38
Titel:

Wal hat folgendes geschrieben:

so, aus Donnerstag / freitag wurde zwar sonntag, aber egal Smile

habs eben mal getestet, mehr als 50%CPU-Last bekomm ich nicht hin (dann ist aber so ziemlich alles an)

aber ich werde morgen mein system mal neu aufsetzen (hatte nen registry crash, und seither läuft es einfach nimmer sauber) mal schauen ob es da nicht noch weniger wird. muss mir nur erst noch n kräftiges 13,8V Netzteil besorgen (hab nicht schon wieder lust 4Stunden im Auto zu sitzen ...

tow-b.de - Mi 04 Okt, 2006 14:44
Titel:

Hat dein Board kein ATX-Stecker damit du nen normales 230V Netzteil anschließen kannst? ...

Naja das ist aber jetzt OT.. mal sehen wie es denn nun weiter gehen wird. Videos kann FMOD ja leider nicht abspielen..

Wal - Mi 04 Okt, 2006 19:17
Titel:

Für Delphi gibt's ein DSPack für Video (Cam,Video,DirectX u.s.w), das werden wir evtl. nutzen.

Wal

Dirk - Mi 04 Okt, 2006 20:17
Titel:

tow-b.de hat folgendes geschrieben:

schon, aber dazu müsste ich es von der Kofferraum Seitenwand entfernen, und danach wieder anschrauben ... da nehm ich doch lieber ein ATX Netzteil, dass 20A auf der 12V sChiene liefert, und schließe da dass M1 drann an Smile

so, genug OT.

Wal, hast inzwischen was neues zum texten auf nem Epia? hab meinen Rechner neu aufgesetzt, und es ergab nahezu keine Last änderung. werds die Tage nochmal versuchen.

ncc1701a - Sa 07 Okt, 2006 11:37
Titel:

Wo kann man sich denn Delphi als Dev. Plattform einmal ansehen ? Habt Ihr Euch inzwischen für eine neue Plattform entschieden ?

Ich selbst favorisiere für meine Projekte gcc und Qtlib, die Code kann dann für Windows _und_ Linux compiliert werden Smile

Da Maschinencode entsteht läuft das auch auf einem 600er EPIA sehr gut. Klar, das hängt natürlich davon ab, was da für Libs nachgeladen werden müssen.

bluescreen25 - Mo 09 Okt, 2006 20:02
Titel:

http://www.delphipraxis.net/turbo_delphi_download.php

Gruß, bluescreen25

tow-b.de - Di 10 Okt, 2006 15:23
Titel:

Zitat:

Für Delphi gibt's ein DSPack für Video (Cam,Video,DirectX u.s.w), das werden wir evtl. nutzen.

Wie ich oben schonmal erwähnt hatte, wäre es nicht sinnvoll die Media-Player-Funktionalität auch als Modul einzubauen?

Bigdesaster - Di 10 Okt, 2006 20:51
Titel:

Ist eigentlich schon entschieden, wie und auf welcher Platform es mit cPos weitergeht? Question

Macht ja kein Sinn, wenn ich mir jetzt den VB6 Sourcecode reinzieh und dann geht's mit Delphi weiter.

SirGroovy2004 - Mi 11 Okt, 2006 09:24
Titel: Zusammenfassung.

Servus Gemeinde,

mich schreiben wöchentlich Leute an, wie es denn nun um cPos steht. Da sich im Augenblick offensichtlich doch immer wieder die selben Fragen ergeben, habe ich mal versucht eine Zusammenfassung der aktuellen Geschehnisse zu liefern:

Zuerst dachten wir eine Entwicklerecke im cPos Wiki wäre gut. Das hat aber niemand genutzt. Ich habe sie zwischenzeitlich schon wieder komplett entfernt. Für schlichte Diskussionen hat das Forum hergehalten. Dann sind wir über Freepository.com gestolpert. Das ist ganz nett, ist aber langsam und hat eklatante Mängel und Unzulänglichkeiten.

Nun scheint aber ein gutes System gefunden. X3on hat wohl einen Kumpel mit Rootserver vom THW. Auf diesem wird ein CVS System installiert. Hierüber wird die zukünftige Entwicklung von cPos laufen. Auch sollen in Zukunft von dort die "binarys" also relativ stabile Pre Versionen downloadbar sein.

X3on sucht aktuell nach Leuten die das CVS System schon beherrschen und die Verwaltung übernehmen können. Leider bisher vergeblich. Es ist scheinbar doch etwas "exotisch". Wink

Solche Leute werden dringend gesucht!! Sollte sich jemand dessen gewachsen fühlen, so möge er sich bitte mit X3on in Verbindung setzen! z. B.: per ICQ: 46335931

Rytox plant die herausgabe von cPos 1.0. cPos 1.0 wird in einem ordentlichen Setup geliefert werden. So wie in der 022´er Version auf www.cpos-online.de cPos 1.0 basiert noch auf dem veralteten Visual Basic 6 und dem Windows Media Player. Aus diesem Grund wird Ryotx keinerlei neue Funktionen mehr in cPos integrieren. Fragen bringt da garnix. Wink

Was aber unbedingt erwünscht ist, sind Meldungen zu effektiven Bugs von cPos in der bisher aktuellsten Version V500.18. Also bitte testen! Rytox wird diese nach besten können fixen.

Wal plant den Umstieg von VB6 auf Turob Delphi für alle Versionen nach der 1.0. Es sind wohl schon einige Schritte in diese Richtung getan. Skins werden vollständig geladen und mp3 Dateien können abgespielt werden. Es ist aber noch nirgends eine Downloadbare Version erhältlich. Das ist auch noch kein Wunder bei dem geringen Funktionsumfang. Fragen bringt als rein garnix. Wal rückt dann schon irgendwann freiwillig damit raus. Wink

Ebenso setzt Wal seinen Plan um, die Komplette Medienverwaltung über ein neues System laufen zu lassen. Somit hat der Windows Media Player ENDLICH ausgedient. Man braucht sich über Codecs keine Sorgen mehr machen und die flüssige Nutzbarkeit auf den Via Epia Boards ist gewärleistet!

Noch ein Tipp für willige Entwickler: Grundsätzlich kann ich dir nur empfehlen DIREKT den Kontakt zu Wal, Naruto und Rytox zu suchen. Geh ihnen einfach auf die Nüsse und unterbreite ihnen deine Vorschäge und zeige guten Willen. Ausserdem sollte dir bewusst sein, dass die Arbeit an cPos nicht nur Vergügen sein kann. Nervende User ("Ich will verdammtnochmal diese Funktion!!") sind da nur ein Aspekt. Wink

Was wir effektiv suchen:

- Leute die sich im Bereich CVS auskennen, es verwalten, reparieren und ständig pflegen können. Ausserdem müssen diese Leute die Entwickler ansprechen und vielleicht noch etwas Überzeugungsarbeit leisten. Ansprechpartner: X3on

- Eine Person die cPos per Turbo Delphi in verschiedene Module splittet. Dies muss aber vorher mit den anderen Entwicklern unbedingt durchgesprochen werden! Gerade eben hat sich tow-b.de bereiterklärt das zu übernehmen.

- Leute (das kannst auch DU machen Wink

) die die Verison 005.14 auf Fehler durchsuchen und sie Rytox melden. Installiert einfach cPos und nutzt es im Alltag. Wenn euch ein nachvollziebarer Fehler auffällt, gebt bescheid. Aber vergesst eure GENAUEN Hardwarespezifikationen nicht. Alleine ein veralteter Treiber oder ein Windows Update zu wenig könnte theoretisch schon zu Fehlern führen.

Recht herzlichen Dank für die Aufmerksamkeit.

SirGroovy2004

P.S: Ich hoffe ich habe nicht irgendwo was wichtiges vergessen, oder mich generell zu weit aus dem Fenster gehlehnt.

Wal - Mi 11 Okt, 2006 09:24
Titel:

Warum sollte cPOS mit VB6 nicht weiterentwickelt werden ?
Ich möchte nur mit Delphi und mit fmod weitermachen, das hat aber nichts mit dem Ur-cPOS zu tun.Ich denke mal das Naruto mit der VB6-Version weitermacht.

@tow-b.de,
werde auf jeden fall fmod nutzen und auch nur fmod, weder den MP, noch WA und auch nicht FB und erst recht nicht .Net.
Das heißt aber nicht das andere das auch machen müssen. Twisted Evil

Wal

x3on - Mi 11 Okt, 2006 11:11
Titel:

Seh ich das Richtig, dass es dann evtl zwei cPOS Versionen geben wird?
Also wie SirGrooy schon richtig gesagt hab, für Subversion (CVS ist ein anderes System, das wir nicht verwenden werden, solange mir nicht irgendwer gute Gründe dafür nennt *g*) bin ich zuständig. Ich kann vermutlich die Verwaltung und Pflege ned wirklich abgeben, da afaik root-Rechte nötig sind und die bleiben beim Server-Besitzer.
Ich bräuchte also Leute, die mir evtl beim Einrichten etwas zur Seite stehen und vor allem mir helfen die Seite zu testen. Das Einrichten ist wohl weniger das Problem, da es einige Tutorials gibt und so. Am Wochenende werde ich damit anfangen. Da ich aber selber noch nie mit so einem System gearbeitet habe, wär es toll, wenn ich jemanden hätte, der sich in der Hinsicht schon auskennt.
Meine ICQ-Nummer stimmt, bin aber auch hier per PN erreichbar.

Bigdesaster - Mi 11 Okt, 2006 11:16
Titel:

Wal hat folgendes geschrieben:

Das würde ja bedeuten, das es dann 2 verschiedene Versionen von cPos geben wird bzw. das cPos VB6 bleibt und Wal ein neues Projekt in angriff nimmt?

@x3on
Wenn es was zu testen gibt, sag bescheid. An testern wirds nicht mangeln *g*.
Brauchst du Leute mit speziellen Kenntnissen?

@SirGroovy
Hab für Fehler der 500.14 mal nen Thread erstellt. Hoffe das geht so in Ordnung. Klick

FMode - Fr 03 Nov, 2006 12:36
Titel: Re: Die Zukunft von cPOS

vbherodes hat folgendes geschrieben:

<Laienmode>
Eine Vision einer gesplitteten Version könnte so aussehen:

CORE:
- Standardaufgaben
- laden von Plug-Ins
-

MP:
....</Laienmode>

nicht könnte... muss !

Gratulation zu .NET !

(mein Interesse steigt... muss ich mir also mal anschauen...)

Die Protierung BISHERIGER Codes nach VB.NET bietet sich ja nun an...
Neue Module können dann auch Delphi(.NET) oder C# erstellt werden (somit erübrigt sich die Diskussion um C++ oder Turbo Delphi Wink

)

Zur Modularität sei gesagt das es ein Allgemeines Plugin geben sollte. Plugin MP usw... sollte dann vom Objekt "Allgemeines Plugin" erben.

BEVOR nun aber wieder Räder neuerfunden werden (Ich habe 4 davon am Auto - also nix neues !!!) kontaktiert andere .NET Frontends (!).
z.b. Centrafuse und übernehmt dessen Plugin-Schnittselle 1:1 !!!
Ich brauche nicht weiter auf die Vorteile einzugehen ? oder ?
(Knackpunkt dabei: Die Skin-Rendering-engine)

Es gibt auch noch andere .NET Fontends.

.NET Geschwindigkeit:
Ihr solltet keine Massenoperationen in .NET machen (Kopieren) - da gebe ich euch Brief und Siegel - das wird unter .NET langsamer sein als native.
Da aber DirectX usw. nicht in .NET sonder native sind...

vbherodes - Fr 17 Nov, 2006 20:14
Titel:

Mal leise anklopf und nachhorch, wie der aktuelle Stand ist.

gibt es schon was ??

billy - Fr 17 Nov, 2006 20:46
Titel:

bin gerade dabei das auf meinen homeserver zu installieren und freizugeben.

hab aber noch paar probleme mit den rechten auf dem rechner.
wie siehts mit der binary dann aus, kann man die auslagern?? weil sonst geht bei ner neuen version mein i-net nicht mehr. hab nur 40kb/sec upstream.

gruß
billy

billy - Mi 27 Dez, 2006 23:29
Titel:

so um auch diesen Thread auf einen neuen stand zu bringen oder etwas ÖL ins feuer zu gießen.

hab den SVN server am laufen siehe dieser link
http://www.car-pc.info/phpBB2/viewtopic.php?t=14131

gruß
billy

SilverGolfIV - Do 18 Okt, 2007 19:22
Titel:

Hallo zusammen,

Ich bin über einen Kollegen an dieses Forum gekommen, da ich in der nächsten Zeit auch einen CarPC aufbauen möchte. Mein Kollege nutzt auch cPos als Software und ich bin auch ziehmlich begeistert gewesen, als ich es mir bei Ihm mal angesehen habe.
Daher habe ich mich hier mal ein wenig eingelesen und bin dabei auch über diesen Thread gestolpert.

Zur Zeit schreibe ich meine Diplomarbeit im Bereich Software Engineering. Daher habe ich leider auch nicht soviel zeit, da ich aber gesehen habe das für cPOS ein größerer Umbruch ansteht, und wohl noch die ein oder andere Frage im raum steht, würde ich euch gerne meine Hilfe soweit möglich anbieten.

Als ersten vorschlag möchte ich etwas wegen der integration verschiedener Player sagen. In in meinem Arbeits Umfeld ist es üblich mit sogenannten Patterns zu arbeiten. Diese bieten effiziente Wege bestimmte Probleme zu lösen. Als Lösungsansatz für das anbinden verschiedener player wäre zb. das factory patter oder das abstract factory pattern sehr hilfreich.

Vielleicht bringt euch der einsatz dieser pattern entscheidende Vorteile.

Mfg
Christian

billy - Do 18 Okt, 2007 20:50
Titel:

Hallo Christian,

das mit dem plattern (schablonen bzw schnittstellen) ist eine schöne geschichte die kann man bei einer festen vorgabe des softwarewegses machen.

jedoch ist cpos schneller gewachsen als man sich über die verknüpfung der funktionen gedanken gemacht hat. somit ist alles miteineander quer durch den code verknüpft. das plattern welches du meinst wurde schon vielstfach angesprochen. ist aber zeitlich für keinen der programmierer wirklich zu machen.

außerdem müsste dazu mal eine cpos version stehen die so wie sie ist FIX ist. es also nicht alle woche ein kleines bugfix gibt.

die V1.0 wird definitiv nicht mehr gesplittet, danach kann man sich zusammenmailen und über die zugänge im SVN eine teilung machen.

gruß
billy

SilverGolfIV - Do 18 Okt, 2007 21:17
Titel:

mhm, so wie ich es verstanden habe, wird doch gerade versucht cPOS auf eine neue Ebene zu heben. Da ja auch schon eine neue Sprache verwendet werden soll. Daher denke ich das gerade zu einem solchen Zeitpunkt sinnvoll ist zu versuchen, den Code möglichst so auf zu bauen, das es auch für die Entwickler einfacher wird.

Daher auch der Einwand in diese Richtung.

Gruß
Christian

billy - Fr 19 Okt, 2007 12:13
Titel:

also die 1.0 wird definitiv nicht in ner anderen sprache programmiert.

was danach passiert steht noch in den sternen.

gruß
billy

Spot - Mo 03 Dez, 2007 17:06
Titel:

Wird es Cpos auch für Linux geben ?

Ich nutze nur noch Linux (genauer die Distribution ArchLinux) seit 2 Jahren und da bald ein Car-PC ansteht brauch ich noch ne gute Musikverwaltugn dafür Smile

Cpos hört sich interessant an, doch erste Versuche es mit Wine unter Linux zum laufen zu bringen, schlugen fehl....

Wäre schön, wenn es auch unter Linux laufen würde ! Smile

billy - Mo 03 Dez, 2007 17:34
Titel:

cpos ist vom grundgerüst an den windows media player gebunden.

von daher wirds ziemlich schwer, darfst es aber gerne auf linux adaptiere/umprogrammieren

eine alternative wäre z.b. cave live.

Gruß
billy

Spot - Mo 03 Dez, 2007 17:54
Titel:

Ok, danke

dridders - Mo 03 Dez, 2007 17:54
Titel:

cPOS wird auf absehbare Zeit nicht Linux-tauglich werden, dafuer braucht es grundlegende Veraenderungen. In Verbindung mit Wine mag man eine Kruecke hinbekommen, aber wohl niemals etwas womit man gluecklich wird.

Spot - Sa 08 Dez, 2007 14:03
Titel:

Schade

dt01101 - Do 13 März, 2008 11:19
Titel:

Habts schon ein Ergebnis mit welcher Sprache weitergemacht werden soll ?
Falls es mal nen Poll zu dem Thema gab bitte ma den Link dazu posten ,
ansonsten nen Poll erstellen (C++,C#,VB,Delphi, J++ ??)
Ich präferiere C++ & C#. Und da das .NET Framework schon recht mächtig ist und es viele gute OpenSource Libs für viele Anwendungsgebiete gibt würde das die Programmierung sehr vereinfachen.

dridders - Fr 14 März, 2008 20:52
Titel:

C#. Alles andere außer native C++ ist in meinen Augen keine Alternative. VB gehts mal definitiv nicht mit weiter, egal ob .NET oder 6. J++? Wenn dann wohl eher Java, und auch davon halte ich nichts. Delphi? Tot. Hinterher wills noch einer in Cobol machen Wink

dt01101 - Mi 02 Apr, 2008 15:04
Titel:

Cobol ??Vielleicht Modula noch ?? Oder gleich reinen ASM Code .... Hardcore rulez! Razz

dt01101 - Di 08 Apr, 2008 12:35
Titel:

Gibts ne Liste mit den Namen aller die am cPOS entwickeln und welcher Sprachen sie mächtig sind ?

Da ich jetzt erst 1 Tag den SRC vom cPos hab ist es noch schwer die Zusammenhänge nachzuvollziehen. Warum wurde dieses oder jenes so oder so gelöst. Welche Funktionen werden noch benötigt ... wie sollen Sie umgesetzt werden Was will der 'nicht programmierende Teil' der Gemeinde. Für mich die wichtigste Frage: .NET oder net ?

Wenn ich mich recht entsinne hab ich mal was von nem IRC Chat hier auf der seite gelesen ... ist aber bisserl her , gibts den noch ?

Gruß

SirGroovy2004 - Di 08 Apr, 2008 12:49
Titel:

Servus dt01101,

auf Anhieb fallen mir jetz folgende Namen ein: Dridders, Wal, Billy, DU, Fuchs, Janel (oder hies der Schanel...? Oder hat man das nur so ausgesprochen?) Nein. Es existiert keine Liste. Der Zusammenschluss der Programmierer ist sehr locker.

Das IRC Chat ist noch verfügbar. Es würde aber an ein Wunder Grenzen, wenn du alle Devs zur selben Zeit da rein bringst! Smile

Recht herzlichen Dank für die Aufmerksamkeit.

SirGroovy2004

billy - Di 08 Apr, 2008 14:55
Titel:

zu den funktionen die noch gewünscht sind schau mal auf cpos-online.de die vorschläge/fehler

gruß
billy

dt01101 - Di 08 Apr, 2008 16:22
Titel:

Gibt es Absprachen wer was macht? ... jeder hat ja so seine speziellen Präferenzen und Abneigungen. Razz

Wäre gut zu wissen wer daran interessiert ist koordiniert die Programmierung vorran zu treiben und in welcher Sprache das ganze dann läuft.
Wie schon in einem anderen Post gesagt, ich würde DOT.NET als Basis für alle weiteren Entwicklungen bevorzugen da sich dann jeder seine Sprache quasi aussuchen kann. Problem wäre dann der Import bzw. Protierung der Funktionen.
Aus meinen bisherigen Erfahrung bei der Portierung alter VB und C++ Projekte in die aktuelle 2008er NET Versionen ist mir aufgefallen das bis auf vielleicht 4% alles automatisch umgesetzt wird. Problempunkte sind entfernte (obsolete) Funktionen.

Gruß

billy - Di 08 Apr, 2008 16:50
Titel:

also umsetzen/portieren ist nicht ganz sinnvoll meiner meinung da der mediaplayer sehr tief in den strukturen drinnensteckt.

wer was macht, schau mal in die threads zu den jeweiligen anregungen/fehlern, oder schreibe nen thread zur funktion die hinzugefügt wird.

gruß
billy

Der Bora - Di 12 Aug, 2008 18:40
Titel:

ich finde es klasse von euch leuten diese super soft zu entwickeln, macht weiter so Razz

grüße

A-Donut - Do 16 Feb, 2017 23:07
Titel:

Alle Zeiten sind GMT + 1 Stunde
Powered by phpBB2 Plus and Kostenloses Forum based on phpBB