|
I thought CCC is English only - the youngsters does not know Latin...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
A lot of English is derived from Latin.
And from French, German, Old Norse, Greek, Dutch, and a bunch of others that we have adopted over the years ... 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Yes, but wonder if native English speakers do know this specific, without some classic background (I knew it because they forced me to learn Latin as kid  )...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
They tried to teach me it as well, but most of it just bounced off. 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
I would like to thank the other gentlemen for their useful hints.
We don't want another one of these tomorrow, so
DELECTUS
|
|
|
|
|
Latin is the mother of lots of languages - and you solved it so you are up tomorrow - it was an easy clue though despite the Latin part 
"We can't stop here - this is bat country" - Hunter S Thompson - RIP
|
|
|
|
|
Delectus est anagramma de 'celt used'.
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
Romanes eunt domus!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
My little MIDI library is small, and yet in many ways its more advanced than other offerings despite starting out simple.
It's fast. It's small. It's easy to code against (easier than a lot of stuff I've seen). It has a whole lot of features.
So what's the catch? I feel like I want to dive into other people's code to see what they have that I don't.
So far from the little I've seen the stuff just looks more complicated than it needs to be - with midi "pipelines" and things like that.
I don't see the point in features like that. I like K.I.S.S., but even without that I don't know what someone could accomplish that they couldn't with my lib about as easily.
So I'm proud of myself, but a little worried. I've wrapped all of the Windows MIDI API except for patch caching, and my file editing and querying API is pretty good, but it's all very simple, and small. It was almost too easy to code that actual protocol end of it.
I feel like I'm missing something big.
The only complicated part was interfacing with the MIDI hardware.
Real programmers use butterflies
|
|
|
|
|
|
you SHOULD be proud of yourself - and it's ok to look at other people's libraries etc for 'inspiration', but at the end of the day, K.I.S.S., agile and delivery to a client matters, not 'gold-plating'. ok, I think this MIDI collection was just for you, but the principle still holds
(you can bet I'm going to be looking at your work more closely, on one of your interfacing issues you solved  - I'm an ole dog (also OCD*) but I can learn new tricks)
*OCD = Old, Cranky, Dangerous
|
|
|
|
|
i imagine you're talking about my p/invoke witchcraft. it was a necessary evil. I don't really like to get more "clever" than I have to. My p/invokes are usually carefully crafted to avoid having to use GCHandle or Marshal but variable length structures are a killer because the .NET marshaller just doesn't know how to handle it no matter what attributes you mark a struct up with.
Consequently, I have a mess of code that basically streams out a series of structs (each variable length) to a given memory location. I hate it. It's at least mitigated somewhat by the fact that the variable length portion is at the end of the struct, so I use the .NET marshaller to marshal that first fixed length portion rather than doing it myself. That way I can just use GCHandle.AddrOfPinnedObject() and copy that to the desired end location, and then follow that by the variable length portion.
It's ugly, but I got it efficient and robust.
Real programmers use butterflies
|
|
|
|
|
heh - own it/be proud of it - maybe you'll look at it some year(s) hence and be able to do 'better' - more elegant, 'clever' - and there's nothing wrong with being clever now and again - it's like when you solve a gnarly issue with a great LINQ/Lambda combination knowing the sweat it took to learn
and 'clever' - never forget that being cleverer than you look is better than looking cleverer than you are (ripped off from 'Q' on 'Die Another Day')
|
|
|
|
|
My experience is that a LOT of code is not complicated, but made complicated by incompetent developers.
Just an example, I'm working on a (Win)Form where you can enter, save, edit and lookup product data.
I didn't make it, but I'm maintaining the application now.
The first red flag is that the form has database logic, the second is that it has over 1000 lines of code, a third is that the form has quite a few fields.
There's binding in place, but there are still methods like EmptyAddressData which does stuff like PostalCodeTextBox.Text = "".
All in all, this form is hard to maintain and changing one thing will probably lead to bugs.
If not here then in another part of the application, because naming is illogical, to the part where a name does not reflect what it does, nor what the customer calls it, and the original programmer can't remember what it does either, also changes are the same thing is named differently in another part of the application.
Is it difficult?
Hell no, I used to write such forms by the dozen before breakfast* using some reusable components so that the form code could be less than 100 lines.
Was it made difficult?
Obviously, this "programmer" should've retired long ago 
If anything, his programming style prevents you from doing things rather than doing them, despite his line count!
At this point I'm surprised the application works at all.
* Slight exaggeration.
|
|
|
|
|
You're reminding me of how much I hated bizdev.
Real programmers use butterflies
|
|
|
|
|
Size does not matter...
I'm in love with single responsibility and love small, but effective libraries - I can mix them later if I want to create a code monster...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
API footprint does. That's what I mean by size. It directly correlates with learning curve. Sorry i wasn't more clear.
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I feel like I want to dive into other people's code to see what they have that I don't.
I would try to find open source midi controllers, etc. on github, like the old Nulsoft Winamp and extensions other devs have written for this and winamp.
Other than a hobby project for your personal satisfaction as a developer, I think you are very much reinventing the wheel here. MIDI libraries have been around for a very, very long time. I can't possible understand where yours is much different than the countless midi controllers, etc. on github and the internet in general.
Not trying to be jerky here, just giving my honest thoughts on this.
|
|
|
|
|
I haven't found one I liked in c#
Real programmers use butterflies
|
|
|
|
|
fair enough.
then why don't you research the mostly C/C++ ones out there, and see if there is something that you can "borrow" from and port over to C#...if you are truly interested in seeing what you missed or could do better that another dev has done. Just a thought....
|
|
|
|
|
I'll consider it. What I've seen of the C# stuff isn't great. Wet Dry Midi is cool, but it's a different animal, as it's mostly for high level composition of MIDI scores.
In terms of C#, I'm biased but mine kills it.
using(var dev = MidiDevice.Inputs[0])
{
dev.Open();
Console.Error.WriteLine("Recording started. Press a key to stop.");
dev.StartRecording();
Console.ReadKey();
MidiFile mf = dev.EndRecording();
mf.WriteTo("recorded.mid");
Console.Error.WriteLine("Performance saved to recorded.mid");
}
I just typed that up now. I've never seen it easier to sequence and save score, and despite all that you can get down to the metal with it.
Real programmers use butterflies
|
|
|
|
|
I read your article. You have obviously put a lot of time and effort into this. so congrats.
I do see you have the github link at the top of your article. Awesome. i hope it evolves into something great for you then. I am sure other devs out there that are into MIDI etc. will benefit.
|
|
|
|
|
Thanks. Mostly I like the bit twiddling of the protocol wire format and file format. Interfacing with the windows MIDI drivers is kinda fun but also hell because they only very thinly wrap the drivers to expose them to the application layer. There's no real abstraction from the driver code, is what I'm saying, and the interfaces are C based and haven't been updated since the salad days of Windows 95
Real programmers use butterflies
|
|
|
|
|
honey the codewitch wrote: I feel like I'm missing something big.
I used to think that way, then I realized that most other devs were over-designing, poorly designing, or simply not thinking about the problem and hacking together a solution.
Then I looked back at my own code.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
