Gebruikersgegevens.

ben van net dezelfde mening en 'k ben er vrij zeker van dat ze dezelfde fout niet opnieuw zullen maken

dat hangt af van de interface zelf, bv de dmx4all interface emuleerd een seriele poort via usb, dus deze zal even snel gaan, maar een pcdmx(sunlite/dashard) doet dit dan weer niet en hier zal de communicatie pc/interface dus stukken sneller verlopen (lees minder pc belasting). Een interface via de printerpoort is ook vele sneller dan een seriele vanwege de parallelle data overdracht.

staan idd interessante dingen op, weet alleen ook niet meer juist waar en hoe. 'k heb daar ook eens alle mapjes aan 't doorzoeken geweest

Bert, 'k denk dat je best de link naar die build 1 even kunt posten, heb inmiddels ook even geprobeerd met build 7 en daar krijg je idd die fout op. Ik veronderstel dat je die versie nog op de ftp site van martin gevonden hebt?

moest je iemand weten die de interface gebruikt voor z'n eigen geschreven software dan is het mogelijk om het op lj te laten werken. Wat je dus nodig hebt is het stukje code dat nodig is om de interface zelf (hoe hij dus hardwarematig aangestuurd wordt).
Als je dat dan doorstuurd naar mij dan kan 'k proberen die dll daarvoor aan te passen (met de nadruk op proberen)

Ik denk niet dat de warde te hoog gezet kan worden anders zou het wel eens hakkelig kunnen worden.
Nu ik raad je aan het zelf eens uit te proberen, je geraakt vast wel ergens aan visual c++ (bestaan dacht 'k zelfs gratis student licenses voor of je moet het eens aan iemand vragen die informatica studeerd). Ik heb helaas niet altijd de tijd om me er mee bezig te houden. Bij mij doet ie het zonder al te veel problemen op een amd 2800+ en 'n laptop met 'n intel 1300µP dus het zou misschien de combinatie kunnen zijn om alle data door de seriele poort te persen en de dll (ik vraag het bij deze nog eens, heb je al eens geprobeerd de fifo van je seriele poort te veranderen/af te zetten?). Wat je ook kan doen is eens je bronnen en hun processortijd en gehuegen eens bekijken, daar geraak je soms al wat wijzer uit.

en je hebt je interface ook op 38400 baud gezet?

raar ... je hebt veronderstel ik dus even dmx4all.comx even verwijderd en je cpu usage zakt ... ik heb de code van de dll nog eens bekeken. De waardes worden in een aaray gestoken door lj, deze waardes uit de array worden onafhanklijk van de timing van lj doorgezonden naar de interface. Wat ik wel eens kan doen is de sleep time verhogen (wil zeggen dat ik de wachttijd verhoog tussen de eerste lading dmx data en de daarop volgende). Normaal gezien moet dit zeker en vast de cpu time naar beneden brengen. Het optimale daarvan weet ik niet en kan ik ook niet testen omdat 'k de interface niet heb dus je zal verschillende keren opnieuw moeten proberen dan. Maar ik heb er pas terug tijd voor na het weekend ...

Je bent allesinds de eerste die ik hierover hoor klagen, raar dat de anderen hier geen problemen mee hebben. Wat je misschien ook eens kan proberen, je werkt met de usb interface dus er wordt een virtuele com poort gemaakt, probeer eens het fifo register van deze poort uit te schakelen, ik meen dit nog ooit eens ergens te hebben gezien, weet alleen niet meer juist waar.

ik vindt het raar, Lj wacht normaal gezien met z'n volgend pakket data te verzenden als hij van de interface bevestiging gekregen heeft dat de vorige verzonden zijn (daar zorgt normaal gezien die dll voor).
Of er nu wel of niet een interface aanhangt zou in principe geen enkel verschil mogen geven in het cpu verbruik.
Wat je wel eens kan proberen is de dl van de dmx4all interface eens even terug uit de dir te halen en zien wat dan het cpu verbruik is.
Wat je ook het beste kan doen is de 38400baud versie gebruiken want ik weet niet of de 19200 versie wel zo goed werkt.

Daar ben ik ook vrij zeker van dus ik denk niet dat Martin zelf er erg wakker van ligt, blij zijn is anders.
Hoeveel mensen zijn er niet die windows op hun pc hebben draaien zonder er ooit voor betaald te hebben, van de kleine gebruiker ligt Microsoft ook niet wakker, maar van de bedrijven die het zo zouden doen (ik heb indertijd genoeg met de license problemen in bedrijven te maken gehad toen die plots allemaal wakker schoten).

Dit is eigenlijk een verhaal als zovelen. Stel je maakt een chip, zoals intel indertijd deed. Een ander denkt, dat kan ik beter en maakt een chip die hetzelfde doet, met dezelfde software werkt etc etc (nu heb ik het over het intel/atmel en intel/amd verhaal). Tuurlijk zijn ze er dan ook niet blij mee, maar hier was veel geld mee gemoeid bij beide partijen.

Dit verhaal grijpt in op een fout van martin, tuurlijk zijn ze niet blij dat er iemand hun fout ontdekt heeft, als ze dan toch zoveel geinvesteerd hebben in lj, hoe konden ze dan dit over het hoofd gezien hebben!! En ik heb de indruk dat Jens Peter er nu ook niet zo enorm aan verdiend heeft vermits hij Martin verlaten heeft (ontwikkeling van Lj komt niet in gevaar omdat dat overgegeven wordt).

Nu, ik weet niet of er iemand het verhaal van LjFingers al gevolgd heeft? Dat vind ik eigenlijk zo goed als gelijklopend. Martin maakt een interface, noemt het Martin Fingers en vraagt er een behoorlijke som geld voor. Intussen is er weer een slimmerik die de bcf2000 van behringer nogal interresant vindt om lj mee te besturen en schrijft er een programmatje voor. Doet juist hetzelfde als de originele fingers, werkt perfect en vooral nu ondersteund Martin het wel!! Hij heeft er zelfs nog steun voor gekregen en al!! Als je nu aan dit hele verhaal geld zou verdienen, dan ben je verkeerd bezig.

Dus, ik vind dat ze daar hun eigen een beetje tegenspreken ... niet?!?
Ik kan het gerust begrijpen dat het frustrerend is als je net een hele som geld gegeven hebt aan een interface die achteraf bleek niet echt nodig te zijn geweest.
Ik ben er wel zeker van dat ze in Lj3 er voor zullen zorgen dat alleen nog hun interface er op zal werken, helaas pindakaas voor de rest (tenzij ze gewoon met een andere versie van lj blijven werken), maar in de praktijk was het al niet echt moeilijk dit te doen hadden ze iets meer moeite gestoken in hun driver en niet gewoon de originele dashard martinusb genoemd (van professionalisme gesproken).

Indien nu het topic gesloten wordt ga ik ook wel de files weghalen op de server (laat ik het bij deze nog eens zeggen, ik heb ze zelf niet geschreven, ik snap wel hoe het in elkaar zit en van een hack is hier echt niet te spreken, er is met geen haar gekrenkt aan Lj zelf, zelfs niet aan de originele driver).

Dus bij deze heb ik zoiets van, laat leven wat leeft, ik denk dat vele mensen indertijd (en nu nog) blij zijn dat ze eens kunnen "spelen" met een redelijk deftig programma en warm maken voor de volgende versie van Lj (langs deze kant zal martin er wel weer goed mee zijn), bij mij is dat allesinds al gelukt en zit dus in volle hoop te wachten op de volgende versie die dan 99% zeker en vast aangekocht zal worden.