I'm sure there is, but I dunno what to recommend. I've never done web dev with C# or any other microsoft tech. ASP has plenty of frameworks for web services, but you'd obviously have to be using ASP. I'd imagine there's lighter weight, more agnostic C# libs of handling web services if you look though! For local CRUD you can snag just the base SQLite stuff via NuGet, System.Data.SQLite I think?

Let me know what you find out. I generally do that kind of stuff with Python, but I might check it out too if you think the C# way is nice

 

Disclaimer: I haven't read all the replies to this topic. I also don't really understand what OP actually wants to achieve.
EG. Wants to make own VST ? Or just want to synthesize a sound that takes some formal parameters and then outputs those as a strum.

I'd advise MAX/MSP or PureData or SuperCollider or possibly even Chuck. There are some very good open source synths (Stanford SDK/STK, see link at bottom) in Chucks installer that can be modded for PureData. These are based on physically modeled synths. It would not take long to implement long strums (Lots of 8tves) with complicated chords using above mentioned software.

In the case of string synthesis you should look up the Karplus-Strong algorithm. There are a few examples of it being implemented if you google it.

The Stanford SDK includes an implementation of it too

https://ccrma.stanford.edu/software/stk/

 

He doesn't want any of that, he just wants a way to play a chord on a midi keyboard and have it come out sounding like it was strummed, ie: the notes sound staggered a bit rather than all sounding at once. It's a pure MIDI operation to change the note_on timestamp of incoming midi before passing the MIDI onward through the signal chain, no audio manipulation whatsoever

 

II have past the initial learning stage and still struggling a lot to go deeper. I had a project of doing a guitar sequencer in C++ and JUCE, spent some 2 months messing with them and gave in for a while, for the amount of subtleness I have to learn is still large. But I still believe this is the best way to go, despite the hardwork, for the amount of control you have over your project. Tried Reaktor and couldn't cope with that at all.

Let me know about your progress, and if I can help in any way.

 

Yeah I've played around with Reaktor/Synthedit/PureData and they're fine for what they are, but I'd rather just spend the time on a VST with the accompanying infinite flexibility. A full sequencer though is no small task, not surprised you're struggling a bit! I know exactly the hump you're at now, where you're past the basics but still can't figure out how to make JUCE do what you want. The trick is to constantly subdivide your goal so that overwhelmed feeling goes away. That feeling is awful and makes it hard to keep going. You don't want to try working with the goal of "a sequencer" because that's too broad and you WILL get overwhelmed, then frustrated, then give up. Figure out a single task and make THAT your goal.

MIDIStrum related: I figured out why Piz went with the latency-inducing method. You have to do it that way or your strums don't sound like they actually start with the lowest/highest note. Gonna have to redo a chunk of this bad boy now

 

Thank you for all the suggestions. It's overwhelming folks.

Strangely I tried to start such a topic 2 month ago and no one was interested.

Pure Data seems interesting, but for now I think with the PizMidi midiStrum-Fork in C++ we have found the best possible solution.
There is also a person who wants to try a beta in FlowStone, but we didn't see him again for a long time now.

That's interesting. I never could reach "Mr. PizMidi" himself, to ask him about some specs (tried to contact him over his website).
I wish I could help you.

WebServices in C# and VS:
Currently I have no real case and I only should do one hobby project at once.
From what I have heard, there is a dedicated, specialized Lib called WCF (Windows Communication Foundation) which can broadcast messages too. But it seems to be a complete server/client construct.

I'm always using a LAMP infrastructure on backend (no options for ASP etc.), so actually I would only test clients, or the developing of them in C#.

In this case I'm also interested how to targeting platforms on the right/best way.
I mean we can write a C# Webservice client as Windows Forms Application. But would it run on Win 10? Would we have to choose Windows Universal to also targeting Windows Phone, Android and iOS?
Or would we have to convert Windows Forms Application to something Cordova? Must we use Mono to reach the Mac platform too?
There are so many options, I'm a little bit confused. It seems choosing the wrong start point here, can quickly lead to unwanted extra affords. But anyways, it's actually another topic.

Do you know a good C# forum to talk about such things?

PS: Coming partly from the 'evil Flash side'...are there some fancy transition classes in C# to include?

 

Last edited: Jun 20, 2016

LAMP/targeting platform/no-ASP issues are exactly why I've never bothered to explore C# for use in a web environment. It's just too much trouble (IMO) compared to Python/PHP/Ruby/Javascript that all happily run on anything. Plus Microsoft is a huge fan of progress via replacement. Windows Forms is a good example: it's now been deprecated in favor of Windows Presentation Foundation and Microsoft's efforts are now on WPF. Soon enough they'll probably move again. I hate this personally.

The Mono issue is another reason I steer away from C# for anything other than a native Windows-only app. Mono's impressively good, but it's ALWAYS some ways behind .Net in implementation, so you either have to check every code you write to make sure Mono supports it all or risk having something horrible break. Once again, pain in the ass.

Interestingly, this issue extends to C++. Microsoft's toolchain is "helpfully" non-standard in small ways, so it's somewhat of an asshole cross-platform here, too. It's mostly much smaller problems, but they do exist. My favorite example is the C++ standard min and max functions. In normal C++ you can call "float bigNum = std::max(5, 10);" and it puts 10 in bigNum, just like you'd expect. Microsoft for some ridiculous reason long ago decided to make "max" a define in windows header code, so the code in MS compiler doesn't work and the only way to fix it is to know about the problem and add a specific line removing that define. Luckily JUCE handles 99% of the other issues MS causes cross-platform.

Re: forums and transition classes - I have no clue. The C# ecosystem is absolutely huge, so I'm sure both exist, but no idea where to guide you I generally just use StackExchange and Google for everything

 

Thank you Zentropy, good to know.

...interesting...until Win 10 boundary and Azure promotion.

In fact we have to use deprecated and new tech to reach Win 7,8 and 10.
Windows Forms Application + WPF + XAML + WinRt + Windows Universal Apps.
That's no model for my small business.

Would you can reach each version with C++ only?

The story with C# + XAML versus WinJS+HTML5 reminds me of Adobe Action Script + Adobe Flex vs. JavaScript + HTML5.
At the end Adobe gave it in parts to the Apache Foundation to concentrate on JavaScript and HTML5.
A complete tool set died or was 'frozen' in parts.

Update: Tried a 'Hello World' for Windows Universal Apps. Turned out I would have to install Win 10.
No thank you sir- not yet.

 

Last edited: Jun 22, 2016

Hi Jasmine

Long time lurker here but signed up as I like tinkering in Reaktor and thought I'd give this a crack.

Reaktor can indeed do polyphony well. The only real trick is to set the number of voices in the 'instrument' properties, under the Function tab. Then any module can be poly (yellow square bottom right) or mono (orange square) and most can be changed between the 2 if needed.

Anyway, whipped this up quite quickly, It uses 8 voices so up to 8 notes of a chord can be played the same time and it will put a slight delay on each one based on the 'Time' knob. It utilises a module by salamanderanagram (a Reaktor king) available in the Reaktor User Library which allocates midi notes into a normal order, which I then used to pick apart the 8 voices, add delay, and put them back together.

I think this is what you were after anyway???

 

Hey, thank you very much for your contribution!

I think 'unlimited voices' and smooth velocity curves, as it is provided in the C++ solution are features we would hardly miss,
since it will be used together with AAS String Machine (I guess same physical engine as in Abletons tension), modeling a custom 'electronic Vollenweider Harp' via layering and diverse external FX (gated reverb etc.). Which by the way can sound sensational.

But I don't want to be unfriendly or ungrateful.

I will give it a try as soon as I can.

https://en.wikipedia.org/wiki/Andreas_Vollenweider

PS: Some Reaktor Gurus told me NI Reaktor will have timing problems (producing random crap) in this case, as long as no custom FIFO buffer is used. Now we can test this thesis too- assuming it's not included.

PPS: Some say 'the Harp is the instrument of Angles'. Our world needs more harp sounds.

Update: Just tested the ensemble.

Result:
1. I can confirm the 'FIFO buffer thesis'. update->buffers are never good for real-time.
2. It gives me audio crackles in Cubase. This could be related to the absence of a custom, dedicated note off module.
There is one on a dev website, but I don't remember the address.

Nice work, I did nearly the same before... If you want, I can search for the note off module a little longer (just PM me).
I should have it on disc too.
Unfortunately for our main mission, it's not the right approach (reliability, up/down strums, voices, velocity, automation).

 

Last edited: Jun 26, 2016

That FIFO buffer problem is caused exactly by why my first idea re: note delay didn't work and I'm having to redo it Piz's way with new modifications to address his plugin's issues.

You actually cannot use a FIFO buffer at all no matter how custom it is. FIFO will always cause garbage from live use. You can make one work by hand laying the MIDI input, but that defeats the purpose since if you're hand drawing MIDI you have no need of strum since you can just do it yourself. The problem is easy to visualize if you remember that MIDI is strictly sequential and has no concept of "chords". Playing a chord on a MIDI keyboard causes data to be laid out in sequence with no 2 notes being triggered at EXACTLY the same time. They're always separated by at least a few samples (generally many more than a few, in testing...think hundreds). If your playing the chord sends midi such that, say, the second note of your chord happens 100 samples before the first (almost guaranteed the chord notes are out of order somewhere every chord you play), then FIFO buffer causes your strum to start in the middle of the chord and jump around rather than high > low or low > high. This is why FIFO can never work for this situation.

It makes the code much more complex not to use FIFO and I'm not sure if Reaktor will even let you create and sort lists or sequences as a custom buffer. If it does, you can try altering your Reaktor to use the algorithm I'm using now in the C++. It is this:

> Accept 2 parameters. One parameter represents the time period that the algorithm will consider all notes happening within as a "chord". The other parameter is the delay length between chord notes to use for the "strum".
> Take incoming MIDI data. If the algorithm currently has no midi notes, take the incoming MIDI note that happens first (timestamp) and declare it the beginning of a new chord.
> From that first note's timestamp, collect all incoming MIDI notes that have timestamps within the time period given by param 1 above. These are considered the rest of the notes belonging to the new chord.
> (This is the step where FIFO breaks and also where Piz's fails, though for different reasons) Sort the collected buffer of MIDI notes by pitch, not timestamp. Iterate through this list either forward or backward (depending on up strum or down strum) and change each timestamp to be the beginning timestamp + (delay length parameter * # of note in chord). Hand this new MIDI data onward to the DAW from our plugin's output.

This leaves out a lot of the nuance I'm adding to the C++ but since I dunno how capable Reaktor is, this is the basic process for properly strumming. In any case it's fun to play with. It's turning out a lot more complicated than it sounded at first, but I think it's going to be a really cool plugin once finished. Found I rather enjoy writing plugins in this way (for a specific use someone else has) compared to stuff that I come up with on my own that nobody else might ever care to use.

 

Then, when I understood the NI Reaktor Gurus right, no Reaktor solution will ever be able to beat your code, since it actually needs a buffer, because of its architecture/real-time limitations, when it comes to advanced midi chord processing (random results).

 

Last edited: Jun 22, 2016

Because timing is important, if I was to get around this, I would rather practice to play the chords in a strummed fashion and have a lot more variety and expressiveness than static delays between individual notes.
Other than that, two options come into my mind:
- Bome Midi Translator is scriptable, has delay and logic elements and *may* be a scripting environment you could use for that purpose. Also, it works in every DAW
- PureData would be another option, certainly precise enough in timing, and what I like a lot about it is that it's multi-platform. You could even use an old iPod Touch or iPhone used as a touch-controllable standalone midi processor or as a Midi "Plugin" in any Win or Mac DAW, using one of the Midi-Over-USB apps. Only downside is that although PD is no programming language, it asks for some learning time nonetheless.

 

@Jas: Yup if Reaktor won't let you create arbitrary-length buffers and alter the VST's delay latency at runtime inside of it, this is never doable properly in Reaktor. It seems odd to me that Reaktor would have that limitation since many, many effects depend upon buffers like this. I may check it out someday out of curiosity now

@timing - I was just posting a quick algorithm for accomplishing strum in case that guy wanted to use it in his Reaktor solution. The actual C++ version allows and handles for such things as delay and velocity variation precisely to combat the static sound, that's part of the nuance I referenced. I'm not a very good piano player but I'm not too sure how feasible it would be to learn to "strum" with a piano properly. Slow strums that are almost arpeggios, sure, but a quick/aggressive strum happens pretty fast in people-terms. If nothing else, I'd think you'd get tired pretty fast trying to strum a piano

@Bome - Bome's is fantastic and 100% of my MIDI goes through it before hitting my DAW. You can do some REALLY cool stuff with it and I'd hate not having it. This, however, is not one of those things. I popped it open just now to make sure -- the outgoing delay is static and events are independent. That means there's no way to delay a note for differing amounts of time, it's either delayed for, say, 20ms every time the note is pressed or it's never delayed at all. You also can't make more than one trigger for two notes. The only way to handle cases in Bome's where the script depends on more than one note being pressed is to have a single event capture every note you're interested in, which means your choices for output are either outputting a single note or outputting the same data for EVERY note.

@PureData - pd as I understand it is essentially an open source (long-ago)fork of Max, so I'd assume it could do the job eventually, but I'm not sure what the incentive would be. It's going to run slower, use more resources, and offer nothing that C++ can't do. JUCE is about as multi-platform as it gets, as I can build for Windows, OSX, Linux, Android, and iOS at the same time in one click.

 

I took a deeper look into asdfasdf strummer ensemble and saw a custom voice allocator.

Module Info:
"Incoming MIDI notes are assigned to the first voice that does not already contain a value, as opposed to Reaktor's seemingly random voice allocation method."

...seems to be an important hint related to NI Reaktor.

@fiction: I'm not such a good player. I would even prefer one finger triggering via Cubase chord pads and additionally CC automation in real-time or post, then multi tracking, open chords variations and fine tuning in the note editor for good grooving and 'pristine clean productions'.

I did some stuff before and there are parts- no one would play manually (a hell of editing), because of human limitations- or you are such a great artist like Andreas Vollenweider (see videos), with decades of experience.

There are some other technical limitations- which can have been hinted with some 'nerdy but genius stuff'...

Electric Harp

 

Last edited: Jun 22, 2016

Of course, that's all only a way around C/C++. And has its own charm because it's multi-platform.
I agree that realizing a strummer using PD is certainly not a matter of minutes.

 

Update: my version's compiling and working as of 5 minutes ago. Gotta clean up the code before I post it here for testing since right now 7 different debug windows pop up along with the plugin :D I think I'll have a version ready for you guys to test and me to tweak by tomorrow, yay!

^^ Honestly that's almost certainly the best suggestion for people who can't write their own VST code. I only know of it really from seeing what people create in Ableton w/ Max4Live but it's really damn powerful for a graphical environment. After finding out about Reaktor's issues above, I don't think anything else even comes close to Max/PD.

 

Last edited: Jun 22, 2016

Congratulations Zentropy, take your time. The world was waiting for this for so long- so it doesn't really matter which day you come out.

PS: I decided to learn C# and hope the .NET platform don't disappear in the next 5-10 years.
I also take a closer look to C++, to extend my skill set.

By the way, could you tell something about the cross platform advantages of Python vs. C# in detail/practise?

 

Last edited: Jun 24, 2016

.Net's not going anywhere! It'll evolve in plenty of directions constantly since it's Microsoft, but C# is really firmly entrenched in the enterprise application space. Definitely a safe bet in the near future. The big reason C#'s visibility is generally lower than "popular" stuff like Ruby on Rails is just a result of the market for each. You hear a lot more on the internet about startups/startup culture than you do huge enterprises. Startup culture tends toward Rails-esque "new" technologies. Large companies tend toward stable/proven "enterprise" oriented stuff like C# and J2EE, but they don't talk about it like startups do. C# is extremely in-demand for a lot of big companies, so it's not wasted time spent at all.

Re cross-platform: they're both technically cross-platform...the difference is in the ideology behind each. Python was created with cross platform in mind and it shows. Aside from sometimes encountering OS-based issues like handling of symlinks, any Python that runs on Windows will do the same on OSX or Linux. I don't think there are any OS issues that the standard Py libs don't handle, so porting Python from one OS to another is essentially painless. It "just works" because it was designed to. C# is on the other end of the spectrum. .Net is technically open source, but Microsoft's financial interests are in the Windows ecosystem period (until very recently). That's why Mono is consistently behind - Microsoft doesn't give a shit about it. They don't make any cash from Mono. They make a lot of cash from companies buying into the Microsoft-driven ecosystem surrounding Windows-.Net.

Which brings us to the most important point of the discussion--the ecosystem is AT LEAST as important as the technology. Regardless of which you go with, it's inevitable that you're going to not know how to do things and need to Google plenty for answers -- that's just the nature of programming anything. With Python, no matter what platform you're using, there's a million other people also using it and the answer to your question is probably already out there in a bunch of places (StackExchange). With .Net Windows, same deal, tons of other people using it who've already encountered and solved your issue. Mono/.Net on non-Windows - NOPE. This culture is not very large. It does exist, but in nowhere the same size as the others. You're going to be on your own MUCH MORE here than you would be using Python or .Net in Windows. The more experience programming you have, the more you understand how absolutely catastrophic this situation is in any sort of critical/business setting. It's fine if you're just tinkering and can't figure out why your app sets a puppy on fire every time you use it, but when you or someone else is losing money from it, it's not workable.

Re: Plugin - Found the other error with Piz & Complex mode by sheer accident while cleaning up my implementation and it was pretty insidious. Piz worked fine at the time, but it's so old it doesn't strictly conform to the VST SDK anymore WRT parameter handling. It ends up in undefined territory so it sometimes works just fine and other times bad stuff happens. Gotta gut that section now

 

Thank you very much for the details Zentropy. I'm learning a lot in this thread- which I did not expected.