Visual Basic und C# unterscheiden sich nicht groß voneinander, soweit ich weiß. Natürlich werden jetzt einige kommen und mir versuchen zu erklären, dass es schon einige Unterschiede gibt, allerdings bin ich der Meinung dass es auf den ersten Blick recht identisch ist.
Wenn du VB beherscht, ist die Umstellung auf C# sowieso nicht schwer. Das geht ganz flott, wenn man sich ein bisschen konzentriert und noch etwas dazulernen möchte.

Das ist wirklich so. Das einzige was sich bei VB.NET und C# ein bisschen unterscheidet ist die Syntax. Raus kommt der genau gleiche IL-Zwischencode. Für Musikanwendungen kann man vieles nehmen. Auch VB oder C#, wie bspw. hier: CSCore - Highperformance Audiobibliothek Das ist OpenSource und in C#. C++ ist eben deutlich Leistungsstärker, aber keine Sprache, welche man nach ca. 2 Stunden einarbeitung gut beherrscht.

Edit:

​Da habe ich dann in vielleicht einem Jahr begriffen, wie VB funktioniert und muss dann feststellen, dass sich meine Vorhaben damit gar nicht realisieren lassen.

- Wenn du dich ein bisschen hier im Forum anschaust findest du gute Tutorials. Wenn man wirklich den Willen hat, kann man VB in 1 Tag lernen. Wenn man morgens anfängt und Abends aufhört. C++ ist da deutlich schwerer... Und Java ist vielleicht auch nicht die beste Wahl, allein schon aus dem Grund, weil es einfach, sehr einfach zu dekompillieren ist.

​Allows blocks of unsafe code (like C++/CLI) via the unsafe keyword, and support for pointers
Partial Interfaces
Multi-line and intra-line comments (the Visual Studio IDE supports multi-line commenting for Visual Basic .NET)
Multi-line strings with the @ symbol
Static classes (classes which cannot contain any non-static members, although VB.NET's Modules are essentially sealed static classes with additional semantics)
Can use checked and unchecked contexts for fine-grained control of overflow/underflow checking
Iterative for-loops can contain multiple conditionals, such as for(int i = 0; i < 10 && somethingTrue; i++)
The getter and setter of a property may implement separate interfaces. In VB you'd have to define two properties instead: a read-only property implementing one interface, and a write-only property implementing the other interface.

​By default, numeric operations are not checked. This results in slightly faster code, at the risk that numeric overflows will not be detected. However, the programmer can place arithmetic operations into a checked context to activate overflow checking. (It can be done in Visual Basic by checking an option)
C# identifiers are case-sensitive.

en.wikipedia.org/wiki/Comparis…arp_and_Visual_Basic_.NET

OOP hast du in jeder (VB.Net, C#, C++) drin. Realisieren lässt sichs auch in allen, du hast die Qual der Wahl. Wobei C++ anspruchsvoller als C# und VB ist und man damit erstmal n Jährchen am Lernen ist. C++ bietet viel mehr Sprachfeatures und C#/VB bieten eine sehr ausgedehnte und breit gefächerte Standardbibliothek.

ichduersie schrieb:

Wenn man wirklich den Willen hat, kann man VB in 1 Tag lernen. Wenn man morgens anfängt und Abends aufhört.

Da kann ich dir leider nicht zustimmen...

Wieso nicht? Schau dir mal Visual Basic an. Das Namespace-Klassen-Sub/Function-System hat man schnell erlernt. Ein Namespace dient zur Orientierung, und zum Anlegen einer Baumstruktur, d.h. auch eben zur Übersichtlichkeit. Eine Klasse ist so gesehen eine Sammlung von Subs und Functions. Eine Sub ist eine Funktion ohne Rückgabewerte, und eine Function eine mit.

Variablen kann man entweder mit Dim oder mit Schlüsselworten deklarieren, welche angeben, bis auf welche Ebene die Variable freigegeben ist. Ich weiß, der Satz ist schlecht formuliert, aber dass soll auch kein Tutorial sein, sondern nur veranschaulichen, dass man VB recht einfach lernen kann. Und glaub mir, man schaft dass an einem Tag!

Nöp. Allein bis alle Syntaxkonstrukte sitzen und man Aufbau des OO-Systems verstanden hat, ist der Tag schon seit Langem um. Davon mal abgesehen lernt man eine Sprache nie vollständig, man lernt kontinuierlich Dinge dazu.

Die meisten Leute die so etwas behaupten, können es selber noch nicht, bzw haben noch nicht alles gesehen / ausprobiert.

Was ich damit meinte, ist natürlich nicht, dass man die komplette Sprache mit allem Zeug an einem Tag lernen kann, sondern zumindest die Basics (schlechtes Wortspiel...), um ein Halbwegs anständiges Programm mit grafischer Oberfläche schreiben zu können (Gott sei dank gibt es WYSIWYG).

Edit: Und das schafft man an einem Tag.

Du meinst wohl ein Programm das funktioniert, aber ob es ordentlich ist mit dem kleinen Know-How ist eine andere Sache!

Nun aber Back To Topic!

ichduersie schrieb:

Gott sei dank gibt es WYSIWYG

Geht bei 2 Monitoren mal schnell vor die Hose.
C# und / oder VB.NET.
Es gibt einige Feinheiten in C#, die gubt es in VB.NET nicht, z.B. unsave.
Für C++ brauchst Du ca. 1 Jahr, um halbwegs ordentlich mit arbeiten zu können, alles, was GUI ist, ist in .NET deutlich besser, ohne jetzt WPF sagen zu wollen.

Es heißt übrigens unsafe. Deine Vorposter haben das bereits richtig geschrieben

also von Visual Basic und C# finde ich C# eindeutig besser. C# ist um einiges übersichtlicher als Visual Basic. Auch zu empfehlen ist Java. Ich lerne zurzeit Java, einige grosse & kleine Unterschiede zu C# aber der Syntax sieht fast gleich aus....

Java ist nicht zu empfehlen, ansonsten hast du frei Wahl.

Maik H. schrieb:

Visual Basic und C# unterscheiden sich nicht groß voneinander, soweit ich weiß.

Kommt sich auf den Verwendungszweck drauf an.

ichduersie schrieb:

Raus kommt der genau gleiche IL-Zwischencode.

Auch das stimmt so nicht. Ich hatte selbst schon öfters Unterschiede im IL Code festgestellt.

Was jedoch mal generell die Unterschiede zwischen C# und VB.NET angeht:
Natürlich fällt einem als erstes unsafe Code ein. Mag für viele unwichtig sein. Kann auch sein, dass das eine durchschnittliche Anwendung nicht oft braucht. Sobald man jedoch mit Audio arbeitet braucht man das Zeug täglich.
Es geht dabei einfach in erster Linie um Performance. Sobald da etwas nur wenige Millisekunden länger dauert, so hört man das einfach. Zudem arbeitet man nahezu dauernd mit großen Speicherblöcken bestehend aus Rohdaten. Hier kann die Verwendung von Pointern das Leben enorm vereinfachen. Zudem sind diese dort oftmals um einiges schneller und somit zu bevorzugen. Ich verwende bei CSCore täglich unsafe Code und ganz im ernst... ich hätte keine Ahnung wie ich ohne unsafe Code diese Bibliothek schreiben könnte. Macht man das alles mit der IntPtr Struktur und den ganzen Marshalling Klassen etc., so kommt morgen noch kein Ton aus den Lautsprechern.

Doch man sollte auch den Unterschied zwischen C# und VB.NET nicht auf unsafe Code reduzieren. Einige Dinge hat ThuCommix oben schon genannt. Da gibt es jedoch noch wesentlich mehr.
Man mag es nicht oft brauche, doch wenn man es braucht, dann ist man froh, dass es das gibt. Ich spreche von inoffiziellen Features von C# wie zum Beispiel dem __makeref Operatorschlüsselwort.
Doch das ist bei weitem nicht alles. Hier sind ein paar sehr interessante Dinge aufgelistet die C# kann: stackoverflow.com/questions/9033/hidden-features-of-c. Viele davon werden von VB nicht unterstützt. Umgekehrt natürlich auch. Manche Dinge werden von C# nicht unterstützt. z.B. Xml Literale oder das Handles Schlüsselwort.

Wenn wir damit anfangen, könnte ich dir auch mal die Kernsprachfeatures nennen, die C++ im gegensatz zu .Net hat.

Es gibt Mehrfachvererbung. Du kannst problemlos von mehreren Klassen erben, wobei man auch Schnittstellen benutzen kann. Man hat Stacksemantics für Referenztypen, was den großen Vorteil der automatischen Speicherbereinigung an sich hat und ausserdem für für Locks von Mutexes ganz praktisch ist. Gibt kein IDisposeable oder so, du gibst Speicher selten manuell frei. Es gibt konstante Memberfunktionen, entsprechend auch konstante Referenzen, konstante Zeiger und Zeiger auf konstante Objekte. Es gibt den Kopierkonstruktor, der dir autom. eine Kopie der Klasse gibt. Da soetwas auch oft ungewollt ist (grade bei Rückgabetypen (z.B. n vector<>)) gibt es auch Movekonstruktoren. Die bewegen die Daten in eine neue Instanz ohne neuen Speicher zu allokieren, falls das nicht geht, wird kopiert. Entsprechend gibt es auch R-Values und auch Konstante (type&&, const type&&). Diese sind immer da und können überladen, selber definiert oder gelöscht werden. Das Feature, dass C++ ausmacht sind Templates. Damit lässt sich zu 99% jede erdenkliche Architektur realisieren, die man sich ausdenken kann. Kann man aber erst dann wirklich beurteilen, wenn man damit arbeitet (deswegen brauchst man mind. 1 Jahr um C++ zu lesen). Es gibt Functiontemplates, Classtemplates und für structs dasselbe (eine Klasse und eine Struktur sind absolut dasselbe, bis auf die autom. Zugriffsstufe (struct: public, class: private). Folglich kann man Strukturen, Klassen und Funktionen überladen. Operatoren lassen sich natürlich auch mit einem Template bestücken, in C# kann man Operator nichtmal gescheit überladen. Man hat durch Templates auch eine Variable Anzahl an Parametern. Soetwas ist bei einer simplen max-Funktion schon sinnvoll, ist doch Quatsch sowas 100mal Überladen zu müssen. Delegates sind auch ausgedehnter, es gibt Funktionszeiger und Memberfunctionpointer und die Delegate Klasse: function<>. Die hat ne Variable Anzahl von Argumenten. Man kann aus einer Memberfunktion eine function<void()> machen, aus einer statischen und Lamdas natürlich auch. Das tolle ist, es gibt Binder. So kann man aus float divide(float a, float b); float divide(float a) machen oder float divide(float b), oder float divide() oder float divide(float b, float a) oder int divide(int a, int b);. Man kann sogar eine Memberfunktion weg von ihrer Instanz binden: void class::func() zu void func(class*). Wie gesagt auch void class::func() zu void func(). Soetwas geht allein durch Templates. Ist extrem prakitsch, so kann man einem Event z.B. void(int) ein Delegate void(int, float, abc<xyz>&) hinzufügen. Die ganze Standardbibliothek ist so aufgebaut. So Sachen wie Linq werden dadurch auch ersetzt, besser natürlich .
Bevor ich's vergesse, natürlich ist der Verbrauch von Arbeitsspeicher, die Performance(viell. bald gegessen) und die Programmgröße besser. Man ist auch nicht an eine Platform gebunden. Was du nun nehmen möchtest, ist bei dir. C++ kann mehr als C#/VB.Net und die Standardbibliothek von C#/VB.Net umfasst natürlich alle Windowsinternen Dinge, die die C++ Standardbibliothek nicht hat. Wobei ab C++17 auch kompletter Networksupport drin ist. Leider ist es so, dass der qualitativ bescheidene Code und Libraries in C++ überwiegen. Sieht oft mehr nach C aus. Allein so Sachen wie DirectX sind ein Graus. Deswegen wirst du viel selbst wrappen müssen. Grade für deine Vorhaben würde ich sogar eher zu C# tendieren. Wie gesagt du hast die Wahl. Vielleich guckst du dir mal ein paar Snippets an, machst dich etwas mit jeder Syntax vertraut und entscheidest dann.

thefiloe schrieb:

Sobald da etwas nur wenige Millisekunden länger dauert, so hört man das einfach.

In diesem unteren Bereich richtig spürbar ist das ja eigentlich nur im Monitorbetrieb, wenn z.B. über Midi-Keyboard eingespielt wird und man den Sound aus dem Lautsprecher wegen der D/A-Wandlung mit Verzögerung hört.

Kommst du da bei CSCore in einen vernünftig latenzarmen Bereich?
Wenn ich es richtig verstanden habe, nutzt du WASAPI.
Kommst du da an die Werte ran, die mit ASIO erreichbar sind?

Aber diese Effekte sind ja sowieso unabhängig von der Programmiersprache der Anwendung, sondern hämgen von der verwendeten Schnittstelle ab.

Einfach gesagt, wenn du gut - sehr gut in C++ bist, nimm die Sprache.
Bei guten programmier Fähigkeiten, programmierst du hier deutlich performanter.
Ich denke mal, gerade bei einer Musik Anwendung eignet sich C++ am besten,
da es sehr viele Ressourcen benötigt

Ansonsten -> C#, mit der Sprache arbeite ich zu 95% auf der Arbeit.
Es ist gut zu verstehen, und man bekommt in kurzer Zeit eine Anwendung umgesetzt.

petaod schrieb:

In diesem unteren Bereich richtig spürbar ist das ja eigentlich nur im Monitorbetrieb, wenn z.B. über Midi-Keyboard eingespielt wird und man den Sound aus dem Lautsprecher wegen der D/A-Wandlung mit Verzögerung hört.

Nicht ganz. 5ms können einen gewaltigen Unterschied machen. Da...

petaod schrieb:

Kommst du da bei CSCore in einen vernünftig latenzarmen Bereich?
Wenn ich es richtig verstanden habe, nutzt du WASAPI.
Kommst du da an die Werte ran, die mit ASIO erreichbar sind?

Aber diese Effekte sind ja sowieso unabhängig von der Programmiersprache der Anwendung, sondern hämgen von der verwendeten Schnittstelle ab.

Ja du kommst bis zu15ms.entscheidend für die Latenz istdie Programmiersprache schon auch. Es geht nämlich darum wie schnell du neue Daten liefern kannst. Bei cscore wird innerhalb weniger ms decodiert, Effekte berechnet, konvertiert ,....

EDIT: Sorry das unleserliche Wirrwar (hab auf dem Tablet geschrieben...). Was übrigens auch noch bei Sprachen wie z.B. C# dazu kommt ist der GC welcher dir je nach Situation einen Strich durch die Rechnung machen kann...