[Programmeurs gezocht] Zelf softwareprogrammer bouwen

Kraan

Ouwe rot
Lid sinds
11 april 2004
Berichten
1.975
Locatie
Zwolle
Een maat van me gaat binnenkort een poging wagen een programmer te maken (waarschijnlijk java) voor mijn SX500 en Redsound Darkstar. Uiteraard kan ik via m'n nanocontroller ook de SX500 aansturen, maar ik wil alles in 1 logisch beeld op het scherm hebben, en eventueel patches in de computer opslaan.

Mijn vraag is nu of er hier mensen zijn die hier ervaring mee hebben. Stel dat we ergens tegenaan lopen waar we hulp bij nodig hebben, dan hebben we een direct lijntje. Dit lijkt me makkelijker dan een heel topic ervoor te moeten openen.

Bvd. :biertje:

Edit: Misschien dat een moderator "Programmers" in de titel even in "Programmeurs" kan veranderen.
 
Laatst gewijzigd:
Regel 1 bij programmeren: Don't reinvent the wheel.

Regel 2 bij programmeren: Don't reinvent the square wheel. Er bestaat een afvalberg aan allemaal kleine losse klote-applicaties die allemaal met net een ander framework of een andere programmeur of een andere taal gemaakt zijn, ze zitten allemaal compleet dicht - geen broncode - en worden na een update of 3 niet meer bijgehouden, wat tot gevolg heeft dat die gave editor uit 1998 met geen mogelijkheid meer aan de gang te branden is.

Ik weet dat het ontmoedigend klinkt, maar je hebt iemand die van de grond af gaat beginnen en nog niet veel ervaring heeft ("waarschijnlijk in Java" betekent ook nog een aantal dingen - iets dergelijks moet je een hoop beter en van te voren plannen). Idealiter heb je minimaal 2 personen die er achter kunnen zitten; niet alleen wordt de code dan een hoop beter, maar het werk wordt ook overzichtelijker.

Er zijn een hoop forums en nieuwsgroepen; daar heb je in feite je beste opties. Mijn extragratis tip: mik het op Sourceforge en zorg voor geregelde updates en een hele goede planning; dan heb je misschien de mazzel dat er nog meer mensen energie in steken.
 
tja, 'k ben eind jaren '90 zelf beginnen 'programeren'...

Mijn mening is wel,
"Coden moet je eerst en vooral voor jezelf doen!"
"Niks zo powerfull als iets dat je zelf geschreven hebt,
waar je niet jaren moet wachten op een update,
en waar je niet voor hoeft te betalen, alleen wat creativeit en tijd is nodig..."

Als ik echter moest rekening houden met ieders verlangen,
dus al m'n tijd in programeren steken - inplaats van
zelf nog wat muziek te maken, (want dat gaat niet samen)

"dan had ik me al jaren geleden een DVD-speler gekocht
om ontspannen wat filmkes te bekijken,"

maw. 't is anders een beetje gek om dagen/weken/maanden/jaren
je hersens pijn te doen over de bugs die erin zitten...

1) Begin zo jong mogel'k - 'k ben nu bijna 40,
en nu zou ik niet meer moeten beginnen hoor!
2) Begin met iets simpel
3) Zorg dat 't stabiel is, daar kun je op verder bouwen...
4) Succes!
 
De programmeur in kwestie heeft voldoende basis om een applicatie te bouwen (HBO+WO, beide IT). Dat is het probleem dus niet. Hij gaat er ook vanuit dat het hem gewoon lukt. Ik zoek echter toch contact met iemand die ervaring heeft met iets als bovenstaande puur voor het geval dat.
 
Ik vraag me af waarom je het in Java zou willen schrijven en niet gewoon in C of C++ ?
Zelf werk ik in de IT en mijn ervaring heeft me geleerd dat de opleiding die iemand heeft genoten niets zegt over zijn daadwerkelijke kennis nivo, ik heb mensen meegemaakt die een hoge opleiding hadden maar toch op de een of andere manier de grondbeginsellen niet begrepen.
 
Nou,nou, zijn bepaald geen bemoedigende reacties als ik het zo lees. Een software editor is zeker wel te doen hoor. Jaren geleden in Delphi voor de Microwave 1 ook een editor gemaakt. Het was een goede oefening. En het werkte ook nog.
 
Er bestaan een hoop interessante kant-en-klare componenten waarmee je tijd-efficient iets in elkaar kunt zetten. Kijk vooral zeker een keer naar RtMidi. Een complete Midi lib met gemakkelijke API's (inclusief callbackfuncties voor MIDI Receive). Wel voor C++ en niet voor Java...
 
@Kraan: je hebt email.

Ik vraag me af waarom je het in Java zou willen schrijven en niet gewoon in C of C++ ?
Ik zou het om willen draaien: waarom C/C++ als je het veel makkelijker in Java zou kunnen doen?! C/C++ zijn als talen een stuk lastiger te leren dan Java en ook de leercurve voor het ontwikkelen van middelgrote programma's is een stuk steiler. Uiteindelijk maakt het niet zo heel veel uit, maar het is leuker als je in het begin ook al bezig kunt met het daadwerkelijk oplossen van je gebruikersprobleem i.p.v. dat je met name bezig bent met het leren omgaan van de idio(t)synchracies van een bepaalde omgeving. Ook een voordeel: een groot deel van het programmeeronderwijs is tegenwoordig in Java :)

Zelf werk ik in de IT en mijn ervaring heeft me geleerd dat de opleiding die iemand heeft genoten niets zegt over zijn daadwerkelijke kennis nivo, ik heb mensen meegemaakt die een hoge opleiding hadden maar toch op de een of andere manier de grondbeginsellen niet begrepen.
Helemaal waar: 1 van m'n directe collega's heeft een HBO-opleiding gedaan waar je geen letter bij hoeft te programmeren. Direct daarna bij ons aan de slag gegaan en hij (meta-)programmeert nu alsof hij het al 10 jaar doet ;) Leuk om te zien. Overigens wel de (spreekwoordelijke) uitzondering: meestal is bijzonder goed aan iemands opleiding en CV te zien of het een hoogvlieger die duidelijk snapt waar het allemaal om draait (in software engineering) of iemand die alleen maar handig is in het aan elkaar knopen van wat dingetjes.
 
Vroeger werd programmeer onderwijs gegeven in pascal, maar dat wil niet zeggen dat pascal een taal is om volwaardige programma's in te schrijven.
Het lijkt mij dat een programma in c/c++ beter te porten is naar een ander platform, hoewel java natuurlijk al op meerdere platformen beschikbaar is.
Waarbij "platform" voor mij verder gaat dan alleen Windows/OS X/Linux.
 
Vroeger werd programmeer onderwijs gegeven in pascal, maar dat wil niet zeggen dat pascal een taal is om volwaardige programma's in te schrijven.
Het lijkt mij dat een programma in c/c++ beter te porten is naar een ander platform, hoewel java natuurlijk al op meerdere platformen beschikbaar is.
Waarbij "platform" voor mij verder gaat dan alleen Windows/OS X/Linux.
Suggereer je dat Java geen volwaardige taal is? ;) (Spaar je de moeite: ik hap toch niet!)

Hmmm, over het algemeen heeft C/C++ programmatuur juist snel te maken met porting issues -denk met name aan de GUI en specifieke I/O-afhandeling (zowel file-based als bijv. specifiek babbelen met MIDI-poorten). Granted: Java is niet zondermeer zaligmakend, want het feit dat er een Java framework is voor bepaalde functionaliteit wil niet zeggen dat dat ook daadwerkelijk platform-independent is. Ik denk dat het gebruiken van concepten als separation of concerns, strong cohesion, loosely coupled, dependency injection e.d. veel meer doen om je code daadwerkelijk makkelijk portabel te maken. Ik kan met niet voorstellen dat dat soort zaken ook niet in de C/C++ community ontwikkeld is, maar bij Java is het nogal lastig om daar helemaal niks van mee te krijgen.
 
Er bestaan al open source synth editors in java.
Beter bouw je daar aan verder, of bouw je er een module voor: http://www.jsynthlib.org/
Zoals Yoozer zegt: vind het wiel niet opnieuw uit.

Ik ben Java programmeur in opleiding. Maar ben er nog steeds geen fan van. Voor mij ligt de nadruk veel te weinig op performantie, mij verbaasd het niets dat veel programmeurs veel te weinig weten met wat ze echt bezig zijn: in java is dat ook helemaal niet duidelijk.
Ik vind het dan ook niet echt programmeren, meer een mix tussen scripten en software ontwerp, niet echt programmeren in diepe niveaus zoals in vele andere talen. Gisteren nog zat een vriend-informaticus (universitair) me uit te lachen terwijl ik Eclipse accesors&mutators en constructors liet genereren.. Ik kan er wel inkomen...
Ik begrijp daarom wel neuromancer's opmerking ivm het nut in onderwijs en de volwaardigheid van java.
Wij zien momenteel Cobol en Java.. en daar komt nog dotnet bij
kzie het allemaal niet zitten in feite. meest nuttige van de 3 voor mij is dan nog Java.
 
Laatst gewijzigd:
Wauw, er komt opeens wel heel veel schot in dit topic! Laten we het er in eerste instantie op houden dat de bouwer genoeg ervaren is om zo'n applicatie te bouwen, maar dat hij geen specifieke ervaring heeft op het gebied van iets als een midi-programmer.

@ Meinte, bedankt voor je mail, ik mail je zo terug.

@ Bronswerk, heb je de code nog? Wellicht is het voor ons ook bruikbaar.

Ook bedankt voor de andere bruikbare tips (Rvooh, Bronswerk)!
Ik zal via dit topic even de gang van zaken bijhouden.
 
Dit ziet er inderdaad heel bruikbaar uit. We gaan ons hier even op storten. Als dat werkt, bespaart het inderdaad een boel moeite.

ja, het kan alvast een basis vormen, zoals je ziet is het al eeuwen niet meer geüpdatet..
Staat overigens ook op sourceforge: http://sourceforge.net/projects/jsynthlib/

ik heb zelf al lang de source staan, maar ben er nog niet ingedoken..
post zeker je bevindingen hiermee, ik ben benieuwd.
 
Zonet even naar JSynthLib gekeken. (Dik een jaar geleden ook al 'ns gedaan, maar toen niet zo heel erg diep.)

Het zou een basis kunnen vormen, maar de code base ziet er behoorlijk unmature uit: alle core-stuff zit in 1 grote package, er wordt nogal gebruikt gemaakt van Java-"viezigheidjes" (Reflection om te kijken of een bepaalde class iets kan i.p.v. dat netjes via interfaces te regelen) en vooral lijkt er weinig sprake te zijn van scheiding van lagen (presentatie, domein d.w.z. synth-structuur, persistentie van patches).

Ik ben dus niet zo gecharmeerd van de code base. Ik heb niet zelf geprobeerd een specifieke editor (of eigenlijk: lib driver) ermee te schrijven en ik denk dat dat nog relatief pijnloos is (gezien de bestaande drivers), maar de kans is aanwezig dat je ergens tegenaan loopt en in de core moet gaan lopen hacken.
 
ai das idd wel veel minder

natuurlijk als de uiteindelijke programmeur geen ervaring heeft met midi software schrijven zal die code deels wel leerrijk zijn.
 
Hmmm, over het algemeen heeft C/C++ programmatuur juist snel te maken met porting issues -denk met name aan de GUI en specifieke I/O-afhandeling (zowel file-based als bijv. specifiek babbelen met MIDI-poorten). Granted: Java is niet zondermeer zaligmakend, want het feit dat er een Java framework is voor bepaalde functionaliteit wil niet zeggen dat dat ook daadwerkelijk platform-independent is. Ik denk dat het gebruiken van concepten als separation of concerns, strong cohesion, loosely coupled, dependency injection e.d. veel meer doen om je code daadwerkelijk makkelijk portabel te maken. Ik kan met niet voorstellen dat dat soort zaken ook niet in de C/C++ community ontwikkeld is, maar bij Java is het nogal lastig om daar helemaal niks van mee te krijgen.
Hmm, als het om realtime stuff gaat heb ik weinig aan portabillity, seperation of concerns(zeg, heb je bij Hoogerwoord leren programmeren, :)) wel in zekere mate altijd. Men programmeert in C/C++ simpel omdat de compilers die bestaan heel efficiente executie bewerkstelligen.

Ik heb begrepen dat de Java compilers wel vooruit zijn gegaan, maar je zit nog altijd met die Java engine te kijken. Het is meer een compromis.

Voor MIDI maakt dit hele verhaal niet veel uit natuurlijk, omdat MIDI al zo traag is, volgens protocol.
 
@ Bronswerk, heb je de code nog? Wellicht is het voor ons ook bruikbaar.

Wordt een beetje lastig, de programmatuur staat op een oude pc, die inmiddels verhuist is naar de zolder. Als je het echt wilt hebben zal ik de boel moeten optuigen.

Maar "Juce" al eens gezien? Bestaat uit classes geschikt voor audio en midi. Je kunt je eigen UI bouwen enz. Wel voor C++. Ik wou dat ik dat had 10 jaar geleden...

http://www.rawmaterialsoftware.com/juce/
 
Hmm, als het om realtime stuff gaat heb ik weinig aan portabillity, seperation of concerns(zeg, heb je bij Hoogerwoord leren programmeren, :)) wel in zekere mate altijd. Men programmeert in C/C++ simpel omdat de compilers die bestaan heel efficiente executie bewerkstelligen.

Ik heb begrepen dat de Java compilers wel vooruit zijn gegaan, maar je zit nog altijd met die Java engine te kijken. Het is meer een compromis.

Voor MIDI maakt dit hele verhaal niet veel uit natuurlijk, omdat MIDI al zo traag is, volgens protocol.
Uhmm, 10 jaar geleden had je een punt gehad. Tegenwoordig zijn de JVM's er zo goed in om bytecode naar native code om te zetten (realtime op basis van on-the-fly execution profiling, welteverstaan) dat het verschil of verwaarloosbaar is of zelfs in het voordeel van Java.

Verder is dat hele MIDI-verhaal bijzaak: je doet alleen wat MIDI-communicatie om de SysEx heen en weer te krijgen en het is absurd om te denken dat Java daarvoor te traag zou zijn. Het gaat veel meer om hoe je de zaak intern representeert en daar een presentatielaag op bouwt, tenzij je het fijn vindt om direct byte streams van SysEx te manipuleren.

@Kraan: dat ik niet zo van JSynthLib gecharmeerd ben, wil niet zeggen dat je er niet mee moet beginnen. De Driver subclasses die je moet schrijven, bevatten voornamelijk een beschrijvig van de structuur van de synth (of eigenlijk meer: de SysEx), dus dat is sowieso iets dat je uit moet zoeken.
 
Back
Top