Gebruikersgegevens.

even een reactie ... de dll is zeker en vast niet door een bedrijf ontwikkeld (en ook niet door mij om dit nog eens te benadrukken). Wat ik al dacht zal ook gebeuren en dat is dat martin in hun volgende versie beter gaat uitkijken (jammer dat het misschien op zo'n manier moet gebeuren, maar goed van je fouten leer je en soms kosten ze wat ...). Wat je daar zegt over het ontwikkelen van eigen lichtsturingen, been there done that idd (verschillende zelfs).

Wat ik wel weet is dat ik 9 kansen van de 10, als de nieuwe stabiele versie van de 3 uit is, deze wel officieel zal aanschaffen. Maar wat ik nog altijd niet begrijp is dat de makers van lj het ontwikkelen van lj faders wel aanmoedigd terwijl dat dit toch ook tegen hun eigen winkel is (zie lf fingers)?!? Dus dit laat me zo'n beetje twijfelen over waar ze hun lijn gelegd hebben over wat wel kan en niet.

Wat wel vast staat is dat ik de files van de site ga halen, niet omdat ik het warm voel worden aan m'n voeten, maar omdat ik de contstante vraag van het hoe werkt het nu juist en hoe moet het nu eigenlijk meer als beu ben (ben nu ook eenmaal geen helpdesk). Het stond (en nog steeds staat) duidelijk genoeg beschreven, maar nu komt het verschil erbij dat er iets of wat meer moeite gedaan zal moeten worden om de files in handen te krijgen. Flauw? Tja, je weet wat je wilt en alles kost nu eenmaal moeite zekers?!? Trouwens de files zijn eigenlijk vrij vlot te vinden op het internet.

Indien er echt nog serieuze vragen over zijn wil ik ze nog altjid verder helpen ...

op sunlite werkt het ook (2002 alleen), dashard hernoemen naar dashard_.dll, okdmx naar dashard.dll, rest vh verhaal blijft hetzelfde (trouwens martinusb.dll = dashard.dll vandaar dat het werkt op bijna elke soft die met deze dll werkt)

ok pacific was me voor met de tlbuis

zenders .. zwakstroom. Ik sta toch niet graag in de buurt van een tv zender of gsm basestation. Staan etteljike Kilowatts op. Niet voor niets dat we indertijd met zware shunts moesten testen om ze dan rechtstreeks in gsmpjes in te pluggen!!
Draadloos vermogensoverdracht is perfect mogelijk, maar op beperkte afstand. Kijk bv naar ontwerpen van laadstations voor elektrische auto's (even wat stroom tanken), maar dit is dan weer meer het pricipe van een transfo met een onderbroken kern (zlfde principe als het laadstation voor je elektrisch tandenborstel). Nu een onderbroken transfokern is niets meer als een laagfrequent zendstation. Om het simpel te houden, hoe hoger je frequentie, hoe kleiner je kern en hoe meer je via de lucht kan gaan. Alleen om hoogfrequent grote stromen te gaan schakelen is voor de gewone gebruiker wat te duur. Dan liever een kabeltje betalen
Wat ook leuk is (maar best niet doen) is in een hoogspanningsstation met een TL buis gaan staan, light is in the air (heb dit eens kunnen doen op m'n werk, vandaar). Niet voor niets dat er bij ons onder de alternator staat geschreven dat je er niet met een paecemaker mag komen .
Nog een mooi voorbeeldje van draadloze energie, kijk naar het amerikaanse leger met hun electrokanon, bedoeld om alle electronica waar het op gericht is te koken zonder dat er menslijke slachtoffers vallen. enz enz.
Er vliegt meer sterkstroom door de lucht dan je denkt!! Allemaal elektrosmog zoals ze zeggen.

niets verzenden naa rmodem of whatever, als ge verbinding hebt met je interface zie je het witte scherm voor je. In dit scherm komt de info te staan die je interface zend naar jouw toe. Wat je zelf typt kan goed zijn dat je dat niet te zien krijgt (echo off noemen ze dat dan). dus gewoon heel simpel s drukken, doet ie het dan niet (dus krijg je geen response), dan is je baudrate anders en moet je op een andere rate proberen (dus die 38400).
Weet je, als je interface werkt, blijf er dan overal zo 'n beetje van af, da's misschien nog het verstandigste als je niet weet met wat je bezig bent. Zoveel te minder dat je fout kan doen.

gewoon connectie maken met de juiste compoort, je moet geen bestand ofzo gaan proberen te verzenden. Als je even de handleiding leest dan staan daar duidelijk (voor mij toch allesinds) de handelingen die je moet doen (zoals druk op "s" bv).
Doet ie dan niets, probeer dan verbinding te maken op 38400 bauD, lukt dit wel dan staa tie goed en moet je er dus afblijven (programma dus gewoon terug afsluiten). Meer kan ik ook niet meer zeggen, is duidelijk genoeg denk ik zo, ik kan moeilijk een volledige uitleg gaan geven over hoe je een seriele verbinding maakt, niet?!? Wil je daar meer over weten, zoek dan even rond op het internet, staat duidelijk genoeg zowat overal beschreven

ik weet niet welke ronald heeft gekopieerd. 'k dacht dat _2 ingesteld was voor 38400

idd, start het programma en maak verbinding met je interface (bv via com1), stel je baudrate in (normaal gezien in 't begin 19200) en de rest staat in de handleiding van je interface.
kijk auw een beetje verder dan je neus lang is, je komt al snel een pak verder met eens eerst wa tuit te proberen ipv direct een vraag te stellen.

https://www.thewillows.nl/pdf/DMX44xV4_NL.pdf, pagina 7 (een handleiding is soms toch zo handig als je een apparaatje koopt).
Indien je interface op een andere instelling werkt is het mogelijk dat ie wel werkt, mar vroeg of laat zal het zoiezo problemen geven.
Als je niet weet wat een terminal programma is: zoek eens op hyperterminal in je windows help, kom ja al wat verder mee.

roland, 'k heb even zitten lezen. Je moet wel zien als je zegt van com1 t/m com9 dat je er de juiste dll bij zet, dit werkt alleen met één van de laatste geposte dll's!!
Ten 2e, zie dat je de versie er bij zet van 38400 baud, met de andere ga je je pc teveel belasten en een tragere stream creeren en dan ook niet vergeten bij te vermelden dat ze de interfcace op 38400 baud moeten instellen, anders zal ie niet veel doen. Voor de rest, goed gedaan, krijg 'k misschien wat minder mails om uitleg te geven

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.