[taaladvies] Python multiplatform naar closed

[Wilf]

De afgelopen 4 jaar heb ik per ongeluk een simpel Pythonscriptje laten uitgroeien tot 7k regels multitool bij een bedrijf dat nu failliet is EN NIET DOORSTART.

Verreweg de meeste uren in het script waren sowieso privé. Nu zit ik te denken aan een versie bouwen die ik veilig kan distribueren (closed) om mijn uren dev te beschermen. Het gaat mij dan vooral om bescherming van de broncode.

Nou is deze tool vooral Windows-gericht maar ik gebruik ongeveer 70% van de code ook voor Linux en Mac (hier en daar met aanpassingen).

Ik heb 22 jaar geleden met C++ gewerkt maar dat heb ik, stom stom, al tig jaar ook laten verslonzen ten faveure van de webhype (full on op PHP en Flash gedoken destijds). Daar ben ik ook niet full time mee verder gegaan; ik heb mijn horizon altijd verbreed en bovendien werk ik in een niche met tig verschillende proprietary talen. Er is voor mij dus niet één specifieke taal die ik nu vol inzet buiten Python.

Is C++ ook nog steeds de ‘way to go’ om een multiplatform tool te schrijven? Ik hou niet alle talen bij omdat ik normaal gesproken dev in veel niche-IDE’s.

Ik gebruik nog altijd notepad of Atom (en IDLE) en geen echte IDE dus een bijpassende goede IDE aanraden zou mij ook helpen

Overzicht van de tool (ter verduidelijking):

- Geen desktop GUI
- comms via HTTP, TCP, UDP
- web server aan boord met GUI
- stuurt applicaties en OS aan (vergelijkbaar met een hele bak aan nirsoft tools in één)
- Multiplatform maar hoofdmoot is Windows
- Wanneer sandbox het toelaat ook graag als service draaien (kreeg ik met py2exe > srvstart niet gelukt - dingen als achtergrond veranderen werkte niet)
- Software draait op machines die één taak hebben binnen LAN, wel meestal video maar geen KM of alleen beperkte interactie via touch of controllers


De enige twee dingen waar ik met Python tegenaanloop nu zijn (dus):

- Leesbaarheid van code (iedereen kan het stelen)
- Geen losse instance (moet voor het stoppen van het programma Python stoppen, wat in sommige situaties ongewenst is)

Ik heb deze vraag abusievelijk al gesteld bij de koffiemachine en daar kreeg ik al de tips:

- Rust
- Golang

Ik ga mij straks inlezen of dat past bij mijn eisen en wensen maar hoor graag meer tips (ook over IDE’s)

[Hydra]

Dan maar ff copy-paste van het vorige topic:

Wilf schreef op vrijdag 19 juni 2020 @ 08:30:
Is C++ ook nog steeds de ‘way to go’ om een multiplatform tool te schrijven of zijn er in de afgelopen 20 jaar wellicht andere talen bijgekomen die nu écht de edge hebben en waar ik niks van weet (dat laatste weten jullie natuurlijk niet maar zeg dat m’n taalgebruik op dit moment (naast wat niche) = PHP, JS, Python).

Waarom geen moderne JVM taal als Kotlin? Alle voordelen van Java, geen van de nadelen.

Het is trouwens sowieso heel lastig om code te 'delen' zonder dat mensen het kunnen reverse engineeren. Dat is meer een kwestie van tijd versus waarde dan van de taal die je gebruikt. Je kunt python ook obfuscaten bijvoorbeeld; dan is de code vrijwel niet te volgen.

[F.West98]

Gezien je doeleinden zou ik zelf eens kijken naar C#/.NET Core. Werkt inmiddels multiplatform, je kan er een flexibele webserver mee opzetten voor die requests, maar heeft op Windows erg goede (bijna native) integratie met allerlei system calls en je kan redelijk eenvoudig interop doen met de Win32 dlls. En het kan out-of-the-box als service draaien.

Ik weet niet hoe goed je native dingen op Linux/MacOS kan doen, daar ben ik dan weer niet al te bekend mee.

[RayNbow]

Hydra schreef op vrijdag 19 juni 2020 @ 14:51:
Het is trouwens sowieso heel lastig om code te 'delen' zonder dat mensen het kunnen reverse engineeren.

Als het gaat om specifiek de source code (dus niet reverse engineering in het algemeen), zijn er wel oplossingen om code te beschermen. Het is niet heel goedkoop, maar ik ken een aantal softwarepakketten die beveiligd zijn met Wibu-licentiedongles. De software wordt versleuteld en je hebt een licentiedongle nodig om de software te kunnen draaien. Uiteraard zal dit vast op een of andere manier te kraken zijn, maar de dongle-driver probeert enige vorm van tampering te detecteren en daarop te handelen (door o.a. de licentiesleutel op de dongle onklaar te maken).

[Kalentum]

Als je al alles in python hebt: Je kan python ook compileren naar een binary. Er zijn verschillende oplossingen voor en dan hoef je het niet te herschrijven.

[Ghehe]

Wilf schreef op vrijdag 19 juni 2020 @ 10:06:
- Leesbaarheid van code (iedereen kan het stelen)

Wie gaat je software stelen? Je dwingt toch via licenties af wat er met je software mag gebeuren?
Ben je trouwens zeker dat je 100% van die broncode bezit want als je iets voor je werkgever of als consultant hebt geschreven tijdens de werkuren dan lijkt het mij alsof die software (gedeeltelijk) van het failliete bedrijf is.

[Wilf]

RayNbow schreef op vrijdag 19 juni 2020 @ 15:02:
[...]

Als het gaat om specifiek de source code (dus niet reverse engineering in het algemeen), zijn er wel oplossingen om code te beschermen. Het is niet heel goedkoop, maar ik ken een aantal softwarepakketten die beveiligd zijn met Wibu-licentiedongles. De software wordt versleuteld en je hebt een licentiedongle nodig om de software te kunnen draaien. Uiteraard zal dit vast op een of andere manier te kraken zijn, maar de dongle-driver probeert enige vorm van tampering te detecteren en daarop te handelen (door o.a. de licentiesleutel op de dongle onklaar te maken).

Liever geen (Wibu-)dongles. Kan een crime zijn met VM @ Syno en kost kostbare USB op kleine machines.

Kalentum schreef op vrijdag 19 juni 2020 @ 15:35:
Als je al alles in python hebt: Je kan python ook compileren naar een binary. Er zijn verschillende oplossingen voor en dan hoef je het niet te herschrijven.

Daar ben ik mij van bewust. Ik heb py2exe en $naamVanAndereModule eerder gebruikt. Dat is echter vrij makkelijk te lezen en bracht een subset van issues met zich mee in gebruik (delen van de code zijn slecht te migreren; zeker waar het zichzelf aanroept of herstarten moet).

Misschien moet ik mij niet al te druk maken maar juist omdat ik in een mini-niche werk is het verdedigen van je IP wel wat waard.

Ghehe schreef op vrijdag 19 juni 2020 @ 16:08:
[...]


Wie gaat je software stelen? Je dwingt toch via licenties af wat er met je software mag gebeuren?
Ben je trouwens zeker dat je 100% van die broncode bezit want als je iets voor je werkgever of als consultant hebt geschreven tijdens de werkuren dan lijkt het mij alsof die software (gedeeltelijk) van het failliete bedrijf is.

Mijn taak was niet die software schrijven in de firma. Het bedrijf has ceased to be. It is officially dead. It is no more. Geen doorstart, alle servers gewist. Ik kan nog wel even babbelen met de curator over rechten (had ik ook als tip gekregen in de koffiehoek).

Wie het gaat stelen? Concurrenten. Ik installeer het ergens, ga naar volgend project, anderen kopiëren het en presto; al mijn uren dev gratis en voor niets bij de concurrent. Ik verkoop mijn kennis en kunde naar klant maar klant kan ergens anders bij concurrent SLA afsluiten natuurlijk. Met een handvol concurrenten is dat stiekem ineens zeer waardevol.

[ Voor 18% gewijzigd door Wilf op 19-06-2020 17:43 ]

[esv77]

Ik wou ook met Rust antwoorden maar dat is al gebeurd in het andere topic, daar sluit ik mij bij aan.

[Koenvh]

Waar maak je je vooral zorgen om? Dat het bedrijf zelf de code in kan zien en onderhouden (of iemand daarvoor inhuren), of dat het bedrijf het aan een ander doorgeven kan? Dat tweede kan namelijk gewoon met een goede licentie opgelost worden. Daarvoor zou je een advocaat o.i.d. in kunnen huren.

Dat eerste is al lastiger om te voorkomen met Python, althans, ik weet niet of je dat contractueel kunt verhinderen. Dan is Rust, Go, C++, C of wat dan ook een betere keuze (Java en C# minder, daar het makkelijker is om te decompileren, al is dat ook wel weer te verhinderen).

[GlowMouse]

Of je iets grotendeels in 'privétijd' hebt gedaan, is niet het relevante criterium. Kijk eerst of de tool die je hebt gebouwd toch niet van je baas is. Anders mag je het uit de boedel gaan kopen voordat je er iets mee kunt.

Je zou je een paar cruciale stukjes van je code in een gecompileerde library kunnen onderbrengen. Dat is de makkelijkste manier zonder dat je veel hoeft om te schrijven.

[Wilf]

Koenvh schreef op vrijdag 19 juni 2020 @ 17:52:
Waar maak je je vooral zorgen om? Dat het bedrijf zelf de code in kan zien en onderhouden (of iemand daarvoor inhuren), of dat het bedrijf het aan een ander doorgeven kan? Dat tweede kan namelijk gewoon met een goede licentie opgelost worden. Daarvoor zou je een advocaat o.i.d. in kunnen huren.

Dat eerste is al lastiger om te voorkomen met Python, althans, ik weet niet of je dat contractueel kunt verhinderen. Dan is Rust, Go, C++, C of wat dan ook een betere keuze (Java en C# minder, daar het makkelijker is om te decompileren, al is dat ook wel weer te verhinderen).

Goede vraag. Ik denk beide.

Door de code te lezen wordt m’n werkwijze doorgrond. Ik trek m’n code wel eerst door een module die het ruk maakt om te lezen maar toch

Daarnaast is het dan, voor iemand met een beetje kennis in Python, vrij eenvoudig te gebruiken. M’n script is namelijk zelfhelend (het controleert welke dependencies er wel of niet zijn en repareert ook zelf missende onderdelen).

Ik heb middels ISS ook een installer gemaakt (voor intern) en een 40 pagina dikke manual geschreven die voor intern gebruik is, die is natuurlijk veel waardevoller nog, maar die code zelf is ook leerzaam voor concurrenten. Ik temper er systemen mee waar concurrenten soms nog tegenaan klooien.

Licenties helpen piraterij niet tegen te gaan maar wellicht is het wel een goede juridische tool om misbruik te voorkomen. Issue is dat de software gebruikt wordt in LANs waarbij er geen of zeer beperkte WAN-connectie plaatsvindt dus echte bescherming is een wassen neus.

[Hydra]

Wat doet de tool ongeveer?

[Ghehe]

Koenvh schreef op vrijdag 19 juni 2020 @ 17:52:
ik weet niet of je dat contractueel kunt verhinderen. Dan is Rust, Go, C++, C of wat dan ook een betere keuze (Java en C# minder, daar het makkelijker is om te decompileren, al is dat ook wel weer te verhinderen).

In mijn ervaring wordt er vaak een maintenance & support licentie genomen. Als je ook maar iets aanraakt of niet "fully supported" doet dan krijg je geen support meer.* Je zit natuurlijk ook met het feit dat jij er zelf voor moet zorgen dat je veranderingen met nieuwe versies blijven werken.

* Vaak werken ze met een diagnostics tooltje die allerlei gegevens gaat bundelen zoals logs, OS en packages versies, checksums van files, .... waardoor ze dat in het snotje krijgen.

[Wilf]

Hydra schreef op vrijdag 19 juni 2020 @ 18:31:
Wat doet de tool ongeveer?

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Ghehe schreef op vrijdag 19 juni 2020 @ 19:00:
[...]


In mijn ervaring wordt er vaak een maintenance & support licentie genomen. Als je ook maar iets aanraakt of niet "fully supported" doet dan krijg je geen support meer.* Je zit natuurlijk ook met het feit dat jij er zelf voor moet zorgen dat je veranderingen met nieuwe versies blijven werken.

* Vaak werken ze met een diagnostics tooltje die allerlei gegevens gaat bundelen zoals logs, OS en packages versies, checksums van files, .... waardoor ze dat in het snotje krijgen.

Ondertussen werken overal oudere versies gewoon door. Support is nooit nodig gebleken; heb 0% uitval. Ik heb ook een testtool geschreven die m’n eigen script over de zeik probeert te brengen door alles wat een onkundige gebruiker fout zou doen ook fout doet. Daar heb ik al menig fout mee ondervangen. Verder heb ik een zeer extensieve debug met exception catches zodat ik er snel bovenop zit. Enige zwakte is DoS maar als dat gebeurt in een gesloten LAN heb je andere zorgen.

Ik ontwikkel nog steeds door (zit nu thuis bij beta .40) en die kan weer meer dan de scripts in het veld, echter zijn die al zo krachtig dat het wel eens zonde is om daar te lang over na te denken wat concullega’s kunnen rippen zonder enige vorm van bronvermelding of credits.

Kijk, als het gestolen of gebruikt wordt, sja, dat risico loop je nou eenmaal. Jammer maar helaas. En als een ander bedrijf SLA’s gaat leveren op het netwerk komen ze het vast ook wel tegen, en als ze onderzoek doen kunnen ze het ook vinden en snappen.

Ik hoef er ook niet rijk van te worden (gaat ook niet snel in een niche). Maar nu kan gewoon de gehele code geript worden en concurrenten kunnen de sier maken met m’n code zonder bronvermelding, en dat zou ik wel echt zeer naar vinden. Het is de afgelopen 4 jaar wel een zeer groot deel van mijn leven geworden. Tot wel dagen van 20 uur (vrije dagen) als ik in de zone zat. Het is ook een USP dat ik aan bedrijven bied.

Nou trek ik de productieversies wel door een module heen die alle leesbaarheid vergalt maar een handige dev met leesbril laat zich niet van de wijs brengen natuurlijk.

Het is voor mij dus vooral een erekwestie geworden.

Als ik Rust (nu de aan mij meest aangeraadde taal) multiplatform (Linux, Raspberry, Windows) kan gaan inzetten en dat closed source kan dan ben ik blij. Dan heb ik een nieuwe taal waarin ik wel durf te investeren. Zeker als dat op ‘de markt’ een taal is die potentie heeft om serieuze software te bouwen. Want dan maak ik er gewoon echt wat nuttigs van voor iedereen, openbaar maar wél met credits.

[ Voor 77% gewijzigd door Wilf op 19-06-2020 23:51 ]

[diondokter]

Wilf schreef op vrijdag 19 juni 2020 @ 23:29:
Als ik Rust (nu de aan mij meest aangeraadde taal) multiplatform (Linux, Raspberry, Windows) kan gaan inzetten en dat closed source kan dan ben ik blij. Dan heb ik een nieuwe taal waarin ik wel durf te investeren. Zeker als dat op ‘de markt’ een taal is die potentie heeft om serieuze software te bouwen. Want dan maak ik er gewoon echt wat nuttigs van voor iedereen, openbaar maar wél met credits.

Uit persoonlijke ervaring kan ik het zeer aanbevelen. Zeker ook omdat je een C++ achtergrond hebt.
Natuurlijk kun je dit closed-source doen.
Nadeel is wel dat je er inderdaad wel in moet investeren. Het is prima te doen, maar je moet je wel even open stellen voor nieuwe concepten en accepteren dat het het beste is om gewoon de compiler te volgen.

Ik kan nog een hele rits aan voordelen noemen, maar het beste is het als je eens kijkt naar 'the book'. Dat is de beste introductie. Gewoon lekker hoofdstuk voor hoofdstuk doorheen.

[Wilf]

Thanks, dat helpt mij zeker over de brug.

Bedankt voor jullie adviezen en tips, ik ga weer een nieuwe taal leren (is toch een hobby van me dus komt goed uit ).

By the way: ik lees dat VSCode een veel aangeraden IDE is. Goed idee? Meestal heb ik niet zoveel met IDE’s. Ik werk liefst op MacOS en Windows (eerste ivm tekstrendering (on screen legibility), laatste omdat ik dan gelijk kan testen).

Code al de helft van m’n leven met notepad en laatste jaren met Atom en werd agressief van IDE’s zoals PyCharm en Anaconda die meer voelen alsof je met een loden pak door modder probeert te zwemmen. Bloatware galore. 13 jaar terug had ik wel OK ervaring met de Eclipse suite though.

[ Voor 64% gewijzigd door Wilf op 20-06-2020 01:33 ]

[diondokter]

Voor Rust zijn er IMO twee goede plugins.

VS Code: Rust Analyzer
IntelliJ: InteliJ Rust

[farlane]

Rust is vet cool. Bereid je echter voor op een [ge,ont]wenningsperiode waarbij je gaat vechten met (en verliest van) de borrow checker.
Wij (de borrow checker en ik) hebben elkaar wat ruimte gegeven de laatste tijd, we gaan het voorzichtig weer oppakken in de nabije toekomst

[Wilf]

Ik heb het even gegoogeld en ik zie de valkuil. Ik zal sowieso weer even moeten gaan omschakelen naar JS-achtige inheritance zo te zien (iets wat ik echt lelijk vindt aan JS en zeker niet mis in Python). Maar elke taal heeft z’n eigen bittere pil of hobbel die je moet nemen.

[farlane]

Nu ja, als je laatste C++ ervaring van 22 jaar geleden is zal ook dat een cultuurshock zijn zou je dat gaan gebruiken. C++ vs Rust zou op dan niet veel uitmaken denk ik

[Wilf]

… en stiekem ook interessant voor een andere RTC business case. Ik ben me nu heel erg aan het inlezen in Rust / Go / C++ en zie idd dat C++ nog behoorlijk relevant is.

Ik heb 22 jaar geleden C++ op school gehad maar was destijds meer gecharmeerd van visueel georiënteerde programmeertalen en ver-gaande OS-optimalisatie. Als je jong bent denk je veel praktischer dan lange termijn.

[Ben(V)]

Gewoon Python blijven gebruiken en eventueel alleen de .pyc bestanden ter distributie aanbieden.
Als je denkt dat 7K aan python code zonder opmaak of commentaar te hergebruiken is dan waag ik dat sterk te betwijfelen.

Haal maar eens een public domain python project van github, verwijder alle commentaar en opmaak en probeer maar eens te achterhalen wat het doet.
Ik denk dat je het sneller opnieuw schrijft.

En net zo goed als je .pyc code weer om kunt zetten naar gewoon .py bestand (zonder commentaar en opmaak weliswaar) kun je ook elke willekeurig binary decompileren en weer C code van maken.

Als je er genoeg tijd en energie in stopt kun je alles reverse engineren, maar gaat erom hoeveel het kost en wat het kan opbrengen.

[Wilf]

7k regels is inclusief m’n notes en opmaak. Zonder is het al gauw 2k minder.

Maar ik hoor je. Ik ben inmiddels wel flink aan het oriënteren en inlezen geweest, ook weer terug in C++ en raakte regelmatig op zijpaden (zoals discussies over garbage collection).

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Ben(V)]

Tja als je van python naar iets als C++ gaat kom je er ineens achter wat je dan allemaal zelf moet regelen wat anders gewoon door de python interpreter voor je gedaan wordt

[Immutable]

Ik denk dat hier rust is aangeraden. Echter als ik een product ga ontwikkelen kijk ik eerst wat er al bestaat, en wat ik nodig heb qua libraries en frameworks en kijk ik naar de kwaliteit van deze libraries en frameworks.(Liefst blijf ik weg bij frameworks, omdat het in de toekomst vaak zorgt voor complete rewrites van je project...)

Ik bouw graag op kwaliteit opensource werk van anderen. Eventueel kan je dan namelijk ook bijdragen aan de kwaliteit door PR's en bugfixes waar je zelf tegen aan loopt. (win-win voor samenwerking in opensource)

Voordelen van Rust:

• Is veel productiever als C++
• Compiler helpt je echt heel goed mee.
• Build tools is modern, dus stuk makkelijker om een nieuw project op te zetten en te experimenteren. En heel makkelijk dependencies toevoegen in je TOML file en wordt allemaal automatisch gedownload. easy peasy.
• Eenmaal gewend aan de taal ben ik van mening dat het net zo productief is als Java/C#. Maar wel iets minder als python.
• Het is de meest breed inzetbare taal van de toekomst. Van Microcontrollers tot aan supercomputers tot aan het genereren van WebAssembly. Investeren in deze kennis is low risk high reward.
• Het zit logischer in elkaar dan C++. Het is gebouwd op de fouten die nu voor altijd deel zijn van C++.(En nooit meer verandert kunnen worden)

Nadelen:

• Je zult veel libraries missen, ecosysteem is jong. Meest gebruikelijke libs zijn wel aanwezig. (kijk gewoon of je iets mist. Check: https://crates.io/)
• Compiler is traag(Omdat de compiler veel werk verricht), een snelle computer is een must voor snelle iteraties.
• Je denkwijze moet even om, je hebt geen inheritance, en classes. (De manier van OOP in Rust ga je uiteindelijk waarderen!!! Dus uiteindelijk een voordeel)
• Je denkwijze moet om qua denken in dingen berekenen, naar hoe ga je met je data om en de structuur van je data. Dit is heel belangrijk in rust. En welk stukje code is op een bepaald moment de eigenaar. Dit is een sleutel doorbraak om rust te begrijpen. Eenmaal dit begrepen is er een weg voor je open. Je moet dus gewoon leren hoe "geheugen" werkt en hoe rust daarmee om gaat.
• Er zijn minder mensen die Rust kunnen programmeren, meer mensen die C++ kunnen programmeren.

Tot hier mijn persoonlijke mening als perfectionist qua mening over talen. Nu echt maatadvies: (Ik walg zelf van GC, tenzij een bepaalde algoritme daardoor sneller is)

Als je geen zin hebt in correct geheugenmanagement aanleren zoals bij Rust en het voor je project niet boeit of je een Garbage Collector hebt of niet. Dan raad ik je aan om ook even te kijken naar Go.

Go is een taal dat tussen Systeemtalen en ByteCode runtime talen in zit.(Bytecode Runtime Talen zijn o.a. Java en C#)
Go lijkt mij ook een prima keuze, deze compileert ook naar machinecode toe. Ik zou hier ook eens naar kijken als je geen zin hebt in manual geheugen management e.d. Maar je hebt dan wel een GC, maar omdat je programma eerst op python draaide denk ik dat een GC voor jou beter is. Je time-to-market zal waarschijnlijk inclusief het leren sneller zijn.

Er bestaat ook zoiets als .net Native voor C#...... maar C# gebruikt veel runtime spul in veel libraries en daardoor kun je niet alles zo naar .net Native compileren. Voorbeelden zijn, bepaalde scenario's waarbij je reflectie gebruikt o.i.d.

Het makkelijkste voor jou is een simpele OOP taal met classes(wat je al gewend bent) met Garbage Collector en naar machine taal compileert.
Talen die in deze groep vallen zijn o.a.:

• Go Language
• D
• Nim

Nog meer opties? Ja.

Je kunt je huidige Python code misschien door een converter heen gooien van Python naar Go, of Python naar C++. Vaak zitten er hier en daar "edge cases" aan zulke tools.
Maar als je niet hele speciale dingen doet kan dit enorm veel werk voor je schelen bij een eerste stap om je code om te zetten.
Hier moet je zelf maar even naar googlen.

Voorbeelden:
https://github.com/google/grumpy Python naar Go (Wordt dus omgezet naar machinecode en kan men niet goed meer reverse engineeren)

https://shedskin.readthedocs.io/en/latest/ Python naar C++.

Disclaimer: ik heb geen programmeer opleiding gedaan, en ik programmeer alleen als hobby en een heel klein beetje op mijn werk. En niet met rust helaas

[PainkillA]

mijn ervaring is dat rust nog niet volwassen is zoals golang dat wel is. Zo mist er een fatsoenlijke IDE zoals golang die wel heeft met Goland en verder is de support voor GUI's maar vooral web nog matig

Rust heeft veel potentie maar heeft echt nog een paar jaar nodig daar waar golang al vele jaren mee gaat en wat dat betreft "af" is klaar voor productie systemen op elke schaal

[Wilf]

Nu we toch inhoudelijker over talen gaan (en hopelijk wordt dit niet gezien als kapen van mijn eigen topic):

Ik heb parallel aan dit programma een programma geschreven in Pure Data (een visueel georiënteerde taal) dat ik ook graag naar een cleanere versie breng.

Dat programma doet aan real time audiobewerking (DSP) op basis van wiskundige formules en fysieke modellen. Verder deelt het bepaalde eigenschappen met het Pythonscript wat betreft aansturing en implementatie.

Omdat ik geen bloatware wil maken zou ik dit niet in één script willen douwen maar wel parallel programmeren.

Toen ik jong was stond real time audiobewerking nog een beetje in de kinderschoenen maar bestond Csound wel (destijds moest je compileren). Dat is inmiddels ook in de wereld van real time getrokken.

Nou is Pure Data gebaseerd op C en kan je daar vrij makkelijk ook een GUI in bouwen (met alle computations verborgen in subpatches), dus dan is een GUI weer handiger. Alhoewel ik geloof dat, zoals veel andere software, GUI's op basis van HTTP nu en in de toekomst steeds normaler zijn / worden.

Nou goed, lang verhaal weer, tijd voor een samenvatting.

Het zou fijn zijn als de taal die ik ga kiezen voor TS tool ook prima overweg kan met:

- Real time audio processing (efficiënt)
- complexe formules in audio en control-domein
- GUI friendly of anders server capabilities (zoals TS)
- Netwerk friendly (lijkt mij dat geen enkele taal NIET overweg kan met udp/tcp maar goed)
- Multitask / multicore / multithread friendly (slaat eigenlijk weer op efficiënt)
- Toegang tot netwerkaudioprotocollen (AES 67 / Dante via ASIO bijvoorbeeld) en multichannel (32/32).
Wat ik al heb gedaan is kijken op de websites van alle bekende RT audio software Mfg's om via vacatures te achterhalen welke taal ze gebruiken maar daar zijn ze niet erg open in helaas. Ook diverse searches halen niet de informatie omhoog om, zonder directe ervaring, te bepalen welke taal wel of niet geschikt is.

Ik vond wel deze powerpoint waarin Rust als 'alternative for C/C++ for the brave' genoemd werd.

Ik draai al wel wat machines met Pd in het veld maar de CPU load en memory load zit, zeker met gebruik van multichannel via Dante, soms wel fixed op 60% continu.

In Python heb ik overigens ook al een simpele audio player gebouwd met bestaande modules maar dat is natuurlijk een heel ander verhaal dan rt dsp.

Misschien is het ook allemaal wat hoog gegrepen om dit om te (willen) zetten naar een taal die dit kan en is Pure data ook prima maar ik hou ook erg van uitdagingen en leren is m'n hobby. Van proberen en falen word je ook niet dommer.

[farlane]

C++ wordt een steeds beter optie tov Rust met die wensen in het achterhoofd. De interfacing met C libraries die je ongetwijfeld gaat willen gebruiken met een dergelijke berg aan wensen en low-level gedoe is uitermate goed en performance is als je er geen potje van maakt ook prima.

Wat het GUI gedeelte betreft, tja.....