Looking Forward to helping

Hi!

First and foremost, I'd like to thank you a lot for being interested in this project. As it's still in it's infancy, I am grateful to know that somebody is interested in it, because any feedback is welcome.

For you want to help with windows port, I should at first describe you what is exactly needed to be done.

First note: (I hope it's clear, but I rather mention it, in case it's not) I'd prefer to make the actual source compilable under both LInux and Windows, and not to start a separate project for Windows.

In fact, there should be almost NO work with the GUI. GTKmm (as a cross-platform interface) is said to compile under Windows, and I hope it may be achieved with not too much work. I've never managed (well, I've never tried hard enough) to do so, but I hope it can be done with minimal code changes.

However, more work may be required when it comes to MIDI support. Being sincere, I've never tried to use any MIDI application under Windows, and I have no idea how things are organized on that platform. This means, of course, that I have no idea on how to implement MIDI-related procedures for windows. So it seems, that most of the work that will have to be done on Windows port will include porting the MIDI procedures. I tried to keep everything MIDI-related in file MidiDriver.cpp, so I hope that using a global #if - #else - #endif that would recognize the OS for which it is compiled (for sure Autotools provide something ready for this conditional switch), and putting the actual source into it's first case, and the windows one into the second one, might be a nice solution that would not mess the code too much.

Probably some changes may need to be done when it comes to file access (for example, now directories in file patch are recognized with a '/', while in Windows it's obviously '\' character - minor, but significant), but I am not sure about what exactly must be done.

When it comes to the source, I must admit I know it's quite a mess there. I'm currently doing some refactoring to make it more clear. The 0.13 release is probably almost done, just few minor fixes and I'll release it - I promise to add more comments and explanations to the source, so that it will be easier to understand. I'll also try to find and comment the platform-specific features for you :)

When it comes to work organization: of course it would be most effective if you just started a new branch here, on launchpad. But if you have anything against it - tell me. Because as for now you are the only person willing to help me, I'll take into consideration all your suggestions :)

That's the general idea on how I'd like the windows port to be done. Tell me you ideas, and specify how exacly would you like to do :)

Once again, great thanks for being interested!
Best wishes,
Rafał Cieślak

Hello Rafal!

I'm sorry for the delay in answering you but I guess because of the time
difference (I'm in Texas) this will probably always be the case.

Before I tell you what I'd like to have when this is "finished" I'll
answer your points first:
> First and foremost, I'd like to thank you a lot for being interested in
> this project. As it's still in it's infancy, I am grateful to know that
> somebody is interested in it, because any feedback is welcome.
>
I glad to get in on the "ground floor."
> First note: (I hope it's clear, but I rather mention it, in case it's
> not) I'd prefer to make the actual source compilable under both LInux
> and Windows, and not to start a separate project for Windows.
I agree fully with this idea. If I wanted this only on Windows, I'd
start a separate project.
> In fact, there should be almost NO work with the GUI. GTKmm (as a cross-
> platform interface) is said to compile under Windows, and I hope it may
> be achieved with not too much work. I've never managed (well, I've never
> tried hard enough) to do so, but I hope it can be done with minimal code
> changes.
At least what I've seen of the GUI on the website doesn't look all that
complicated and I don't see it being that difficult compiling for
Windows. I would like to make a suggestion though while the project is
early in it's development stage for you to think about. Have you heard
of "Livecode?" It used to be called Revolution (and before that
HyperCard from the original Mac). I use it quite a bit at work and for
my own projects. You can make amazing GUIs very quickly and the nice
thing about it is it's cross platform (right down to the GUI) so you can
have one code base and then just tell it what platform(s) you want to
build the executables for. On Linux it looks like a Linux app, on OSX
it looks like a Mac app and on Windows it looks like a Windows app. It
also handles the "\" and "/" conversion automatically (because it knows
which platform it's on) so all code is written using the Linux/OSX "/"
format. There is no royalty required for distribution of executables
either.

What would make this very attractive is if the code was divided up into
GUI code and "behind the curtain" code (what actually makes the music).
The two parts could talk to each other using perhaps sockets (which
opens up all kinds of opportunities for collaboration, multiple
inputs/outputs, and such. If you might be interested, let me know and
we can discuss it further.
> However, more work may be required when it comes to MIDI support. Being
> sincere, I've never tried to use any MIDI application under Windows, and
> I have no idea how things are organized on that platform.
That makes two of us! I'm sure the differences won't be that great
though, and perhaps as simple as the order of parameters in a function
call. Perhaps we could use what you already have as a base and then
write "wrappers" for Windows (and maybe OSX) that would accept the call
in Linux "style" and then translate it into whatever format the targeted
platform required. You MidiDriver.cpp file could then stay the same for
Linux.
> Probably some changes may need to be done when it comes to file access (for example, now directories in file patch are recognized with a '/', while in Windows it's obviously '\' character - minor, but significant), but I am not sure about what exactly must be done.
>
See above about LiveCode.
> When it comes to work organization: of course it would be most effective
> if you just started a new branch here, on launchpad. But if you have
> anything against it - tell me. Because as for now you are the only
> person willing to help me, I'll take into consideration all your
> suggestions :)
Since I have never used launchpad, I can't say one way or the other
whether it's good or bad. I haven't done any programming with anyone
else so I've always kept things local. We'll stay on launchpad for now
and see how it goes. If something better comes along or launchpad
doesn't work out, we'll talk about it then. I'm pretty easy to get
along with when it comes to such things.
> Tell me you ideas, and specify how exacly would you like to do :)
Ok, here's where I'm coming from: I have selfish interests when it
comes to this program. My best friend is a song writer and composer
(mostly Country/Americana stuff) and up until now, I've done all the
driving and setup/tear down the sound equipment. I'd like to start
playing with him (he plays guitar only so the venues we can play are
limited and the pay is a lot less than when you have a "band"). I have
a Roland Fantom X-8 keyboard which can make all the sounds I want but
won't sequence well (or easily). Let's say for example I wanted to have
a 1 bar drum loop and a 2 bar R&B type bass loop (both MIDI sequences).
I can set up the drum loop to play on one pad of the X-8 and the bass
loop to play on another (they could also be triggered by keys on the
keyboard). My first problem is that the lengths are different. That's
what intrigued me about your project - multiple sequencers. The other
problem is that if I start the drum loop, as soon as I hit the key for
the bass loop, the drum loop stops (it can only play one at a time).
So, I could fix that by putting the bass and drum loops together in the
same MIDI loop (duplicating the drum loop so it's the same length as the
bass loop) but that only takes care of lets say the I chord. When I
want to switch the the IV chord, I can transpose it up but then the drum
loop transposes too and now all the drums are off, or I could make a
copy of the drum/bass loop with only the bass transposed and put THAT
loop on another key. If I want to add the V chord, I've got to do it
again so now I'm up to three keys but the only thing that's really
changing is where the bass progression starts. If you now add drum
fills, you can see that this quickly can get out of hand trying to
remember which key goes with each bass/drum loop combination. And
that's only one song!

 From a sequencer point of view, I'd like to have them separate so that
once the drum starts, I only have to worry about the bass changes. When
I have a fill, I can let the bass keep going and just hit the key for
the drum fill. Do you understand what I'm talking about? I think I
could get some pretty complex sequences (perhaps played on MIDI foot
pedals) and still leave my hands free to play piano or organ or
whatever. We could go from a 1 piece "band" to a 4 piece and not have
it look like karaoke.

In your video I was looking over the kinds of things you could do on a
key press and while it's a good start, I think there are a lot of other
things that could go on. For example:

1) Play the current sequence x but transpose it 3 semitones up.
2) Play sequence x y times and then go back to sequence x. (Nice for
drum fills which then go back to the main beat)
3) Alternate between sequence x and y
4) "Macros" that would be like smart sequences so that one key could
trigger any number of actions at once.

As you can see, I am asking a lot but I don't think it's anything that's
that hard to do. In order to make this work though, the file format you
use has to be flexible enough to handle the above and also anything we
come up with later, without requiring a rewrite. Perhaps a
mini-compiler that could read your file format (.hseq I think it was)
and then do all the macro expansion and such and create something that
is a little more computer friendly for the actual playback.

By dividing up the project in this way (player, "compiler", GUI, etc.)
it might be easier to get others to help in their area of expertise
without affecting other parts of the program. Of course, what makes all
this work is good documentation describing how all the pieces would talk
to each other and a graceful way to handle things it doesn't understand
(like skipping them). It might also be nice in the future to
accommodate audio files too and we'd just need to make sure that our
definition allows for that possibility and doesn't choke if it doesn't
know what to do with it (i.e., someone with a version 1 of the software
trying to load a version 2 .hseq file.

I've dumped a lot on you but think it over and let me know what you
think. I'm excited to work on this with you!

len

Hello again,

The time zones issue is the case, I live in Poland, but that's not a major problem, there is no need to hurry.

I have one more very important question to you: what OS (or OSes) do you use? Is there any Linux amongst them?

And I am glad to know you got the idea of cross-platform source.

You say you are new to launchpad... Well, it is essential for you to get it know well. Look at it's help materials, the Launchpad Tour, look at other project, because you must know how the things work here. There are thousands of project hosted on launchpad, so you will find many examples how to organize work here. You should also get familiar with Bazaar, the version control system that is used here for storing the source code.

I've never used Livecode, but I looked at it's website, and unfortunately I have to refuse to use it. Livecode is not Free Software, developing harmonySEQ using Livecode would be against it (and mine) philosophy (and probably against harmonySEQ or Livecode's licence). Luckily, I don't see any great advantages of it. A quick to build, easy to code and cross-platrorm GUI: the GTKmm interfece I use has all these features. And handling the '/' and '\' turned out to be a very simple problem, I just had to use string.find_last_of("/\\"); instead of "/". File access will probably cause no major problems.

I only wonder how will treads behave on windows, since harmonySEQ uses two, one for the GUI, one for the MIDI i/o. But that shouldn't be a big trouble, or at least I hope so.

"Wrappers" for windows is the solution I was thinking about. MidiDriver.h contains list of basic functions, like StartQueue() or PauseImmidiatelly(), it's enough to write their equivalents for window's MIDI system. I found no clear documentation on Windows' MIDI, but as I am not a Windows guy, I'll rather not go deeper into Widows' related mess. If you hadn't yet, have a look at MidiDriver.h and .cpp (obtain them from the current branch content, see here: http://bazaar.launchpad.net/~rafalcieslak256/harmonyseq/trunk/files/head%3A/src/). That should give you the idea on how it's done.

When it comes to your selfish interests: you've found the application you need! That's almost exactly what I have designed harmonySEQ for! However, my story is a bit different. I am NOT a musician. I have absolutely NO musician education (except few tips my friend gave me). But I like experimenting with songs, and I spend some time composing music, using my PC and a 25-keys MIDI controller.
One day, about a year ago, I was having some fun with friend's guitar. I had no idea how to play guitar, but since I know some sound theory, I noticed, that if I press any chord (I also had a table of guitar chords) then no matter in what order will I touch the strings, it will sound well. I spend a lot of time repeating a short sequence (like: 2nd string, 3rd, 5th, 4th, 3rd, 5th) and changing the chord from time to time. I thought it would be cool if my PC repeated the sequence, and I just changed the chord with one key, so that I might play lead melody with my other hand and a MIDI keyboard (this is why a chord in harmonySEQ has 6 notes - there were 6 strings in the guitar I had fun with). I spend lots of time looking in the Internet for a sequencer that would satisfy my requirements, but it turned out that there's no thing like that. I decided to do it myself then, and since I was very happy with the result, I wanted to share my results with others.
That's why I am so happy to hear harmonySEQ is THE application you shall find very useful in your performances.

And by the way, I really like the idea of using the sustain pedal for triggering actions, I'll implement it in some free time, since it requires minimum work.

1) Transposing only one sequence by a constant interval is not yet implemented (but can be achieved in a tricky way by changing the chord), but I've already thought about it, and it shall be easy to implement.
2) You mean like automatically triggering another event after some delay? If yes: I've also thought about something like that, but that's not trivial to implement, so I'll better think more about it first.
3) Alternating? Like what? Isn't it the same, or strictly related to 2) ?
4) As for now triggering multiple actions at once is possible. To one event (f.e. keypress) you can bind any number of actions (f.e transposing one sequencer a bit, stopping drums, and changing the pattern of bass). But "macros" is a good idea. That would require LOTS of work, but might result in very interesting results (macros like "if drums are on, then turn the bass off, bind other chord to them, and wait 5 bars, if drums were not turned off, then turn the bass off, blah blah blah").

I don't get the idea of a compiler. Why should we force users to use two applications? harmonySEQ is capable of both playing and performing live and designing the events, patterns and chords. I doubt if there really is any need of dividing it into two pieces... this way as it is now it is really easy to test the sequencers on-the-go, while you are setting up the patterns, or events.
And have a look at the .hseq file with a text editor. It's the simplest form of storing data I know. Easy to read, easy to interpret, easy to control the version etc.

I am very thankful for your ideas and the whole excitement around it. It's great to know you may find harmonySEQ useful in performances!

Rafał Cieślak

Good morning, Rafal,

1) Yes I have Linux around the house. I have a separate server in a
bedroom that runs Linux and acts as a file server, database server, web
server, etc. I've programmed with linux since 1996 or 97 but mostly
with database programs (I use Postgres to this day in a couple of
customer's sites). The only system that is relatively easy to use is a
virtual Ubuntu system my laptop. I have not gotten into the bowels of
kernel programming (or real time programming for that matter) in Linux
but don't see any real problems in picking it up.

Forget Livecode for now. I had forgotten that this was an open source
project. However, I don't think that necessarily excludes Livecode
because you can distribute the source code for YOUR program (not the
development system code) free of any restrictions. But as I said, we
can forget that for now.

I'll start looking over the launchpad documentation so I can get up to
speed using it. I don't think using threads (I think that's what you
meant by "treads") shouldn't be a problem. I must tell you now that
I've never worked with threads (since my work usually relies on setting
things up in the GUI, letting it go off and do some things, and then
displaying results. There are times when the GUI is periodically
updated while the "real work" is being done so it's sort of
thread-like. This idea is what I was talking about with having separate
"programs" do the work - the GUI is one program that starts up and talks
to the "player" part of the program where the real work is done. The
player becomes kind of like a server to the GUI. What makes this
interesting is that if separate programs (think things like grep and cut
etc. that take stdin, perform a task and then write to stdout where
another process is done) are connected with sockets (even on the same
machine) it opens up all kinds of possibilities. For example, my friend
George could have a series of foot pedals that output MIDI (or has an
ethernet cable for output!) and it connects back to the computer I'm
using with my X-8 so that he can trigger his own events even though he
may be 20' away. Or I could "play" something here and control a program
you have running there in Poland! With sockets, it doesn't really
matter where the endpoints are, they can be in the same machine or in
machines halfway around the world. In my case, it would mean we would
only have to lug around one computer when we perform instead of two and
when your traveling in a small hatchback car, space is everything! I
haven't studied the code enough to know if this is even possible or wise
but right now, I think it's at least worth having a look at.

I should add at this point that like you, I am not a musician either.
Yes, I can play chords on a guitar and know where the keys are on a
piano, and can even read music (when I have to). That doesn't make me a
musician. I look at music from a more scientific/mathematical point of
view. It's just easier for me that way. For example, when I talked
about transposing a bass line that's in C, if I want to move it up to F,
I only need to add a constant (5 in this case) to each note in the C
sequence and it will be perfectly transposed to F. If I want G instead,
I add 7 to each note number and I get it in G. It works for any chord.
Where most people mess up is they forget the black keys. I don't think
this will be terribly difficult.

Now to my list of sequence things:
>
> 1) Transposing only one sequence by a constant interval is not yet implemented (but can be achieved in a tricky way by changing the chord), but I've already thought about it, and it shall be easy to implement.
See above
> 2) You mean like automatically triggering another event after some delay? If yes: I've also thought about something like that, but that's not trivial to implement, so I'll better think more about it first.
You've almost got the idea. Let's say I have a 1 bar drum loop
playing. Now I come to the point where I want a drum fill to be
inserted and then go back to the same 1 bar drum loop. Of course, I
could hit a key to start the drum fill and then hit another key to start
the drum loop that WAS playing again, but in most cases, I know I want
to go back to where I was so just pressing one key should be enough. I
don't think this would be that hard to do, especially if you can control
when the loops start. For example, on my X-8, if I have a drum loop
going and press a fill pad/key that loop won't start until the end of
whatever current bar is playing. That way I can press the fill pad a
little BEFORE it's really supposed to start and when the bar comes to an
end, it looks to see if it should play the same loop again or a new one
(in the case of a fill). Because fills in a song might get a little
busy (for example a drum fill and a bass line walk up) if I could press
the key for the fill a couple of beats before it needed to start, I
could be doing something with the bass. I would be very obvious if I
missed the fill by one beat (or even worse, part of a beat) which might
be the case if I got real busy with other things at that time.

3) By "alternating" I simply mean that I might have say two drum loops,
each 1 bar long, and maybe one is "normal" and the other has a crash
cymbal hit in the last beat instead of a hihat. Otherwise they would be
the same. Just to keep the song from sounding like it was done on a
machine, it would be nice to switch back and forth between the two (or 3
or 4) just to keep it interesting. The hard part would be defining it
in the hseq file. Perhaps you could have a list (2 or 3 items) that are
drum loops (all the same length) and any one of them could be used in
this section of the song. You could have a choice of playing one after
the other (like a jukebox) or you could assign a weight to each one.
For example, 80% of the time you'd play loop 1, 5% you'd play loop 2,
and 15% you'd play loop 3. Once this was set up, the "player" would
decide which loop to play for that bar. I think it's much harder to
describe it than to implement it!

4) You've got the idea for multiple actions that I was thinking of.
You've even taken it a step further though with the idea of "if"
statements. I was thinking more of being able to trigger a drum fill
AND a bass line walkup with a single key but your idea of decision
making based on what's already going on is cool too!

This is where the "compiler" I was talking about comes in. It wouldn't
be a separate program really, just a step between hitting the Play
button and music actually coming out. As an example, a SMF Type 1 midi
file has a number of tracks for each instrument. It also stores a
"delta" time for each note that is to be played which relates to the
time since the last note ON THAT TRACK was played. If you start at time
0, in order to get all the instruments to play their notes at the right
time, you have to "compile" each track separately and determine when
it's time to play the next note. It seems to me that it would be so
much easier to run through and do all these calculations BEFORE the song
starts playing than right in the middle of it. Now, maybe you are
calling the midi player at a higher level where it does all of that and
you don't need to worry about it. As I said, I haven't read enough of
the code to see what you send to the sound system so maybe this is a
moot point.

I'll look at the .hseq file this weekend and try to go over some of the
code so I have a better understanding of what you're doing.

Talk to you soon...

len

Good evening (yeah, time zones), Len,

It's good to know you have some Linux, I suggest you to test harmonySEQ (and tell me whether it will compile) and play a bit with it, when connected to any synthesizer, if you haven't done it yet (I have a strange feeling that you didn't experiment with it, but maybe you didn't because of the lack of any harmonySEQ documentation).

As you are going to have a look at the source and .hseq files: I'll include few more, more complex examples of .hseq's in the 0.13, which should be ready within few days. Moreover, you will find it helpful to look at the gtkmm's (and probably Glib's) documentation when reading the source: fortunately these can be easily found in the Internet. Oh, and despite the program's logic is simple, the code is a total mess (I've not yet expected I'll cooperate with anybody). But I promise to add more explanations in comments as soon as it's possible. (by the way, as you are not familiar with launchpad: if you have Bazaar on your system, you can get a copy of the source in the development branch using `bzr branch lp:harmonyseq`, what I recommend, since the last not-yet-released source is the easiest to understand. You can also browse it online: http://bazaar.launchpad.net/~rafalcieslak256/harmonyseq/trunk/files)

Sorry for the typo, of course I meant threads. And I must tell you that I am unfamiliar with sockets (except that I have a basic idea on what are they used for). When it comes to having multiple clients connected to one server (like in the case of a band) I see one trouble: it is all OK when the clients just trigger the events, but what if they started to modify the patch, melodies and patterns simultaneously? What about implementing the feature that would allow harmonySEQ to react on Ethernet events, so in a band one person would run harmonySEQ, and the others would (probably using a minimalistic application) send their events (keypresses, MIDI events) through the Internet? But anyway: there is still long way before any connection between many harmonySEQ instances will be implemented.

I also prefer the "scientific/mathematical point of view" when it comes to music, so I hope we'll understand each other quite well.

Well, in harmonySEQ you do trigger any event a bit BEFORE they should happen, and changes are applied when the next bar begins (in most cases).

In 3) if the alternation is in a constant pattern, then it's already possible to achieve it with harmonySEQ. But the weights describing how often some patterns are played: do you mean that it would require some randomness?

4) So multiple actions you meant already are implemented in harmonySEQ. But the scripting language (when spacebar is pressed: if pattern 1 is played, switch to pattern 2, if 2, switch to 3, if 3, turn off) would require a powerfull interpreter, and might result in many unpredictable crashes (infinite loops etc.). There is also a long way until that would be possible to implement.

When it comes to a compiler and scheduling notes... well, I am not sure what you mean, but I guess I've already got through similar features. Maybe you'll know how to explain this idea better, when you will have looked through the source code.

Rafał Cieślak

Just a quick note: just released 0.13. Have a look at it.

On 12/18/2010 1:01 PM, Rafal Cieslak wrote:
> Your question #138111 on harmonySEQ changed:
> https://answers.launchpad.net/harmonyseq/+question/138111
>
> Rafal Cieslak posted a new comment:
> Just a quick note: just released 0.13. Have a look at it.
>
Will do.

len

As you might experience some trouble with starting a new branch, I did it for you (https://code.launchpad.net/~harmonyseq-win-dev/harmonyseq/harmonySEQ-win), so that you could start working on it (for that purpose I registered a new team, so that we both could work on this branch). I hope as soon as you will get (unless you are) familiar with Bazaar things will become much easier, and you will be able to start committing and pushing changes, merging from time to time from the parent branch (I also will merge it from parent, since any comments that you may find useful I'd rather push to trunk).

The link in previous comment should be: https://code.launchpad.net/~harmonyseq-win-dev/harmonyseq/harmonyseq-win
Sorry for troubles.

Rafal,

Merry Christmas!!

I'm sorry I haven't written back sooner. I did a lot of looking over
the code and also the alsa driver code to try and understand how it's
all put together.

After that initial investigation, I think the best approach is going to
be to get the Linux version to compile and work before I start a Windows
port. Once I can get it to work on my machine (in Linux) then anything
I screw up on my port would have to be something <I> did rather than a
problem in my compile environment. Any other way and I'll have too many
potential places to look for problems.

Now, in trying to understand your code, I got lost with the actual
(physical) MIDI part. It appears that you are letting the Alsa library
to all the heavy lifting of timing. Is this correct? Where I'm coming
from is starting at a SMF and getting it to play correctly. SMFs store
each track (i.e., guitar, bass, drums) in a continuous byte block
followed by the next track, then the next, etc. Also, each event (note
on, note off) has not only the note number and velocity, but also the
delta time from the previous event (FOR THAT TRACK ONLY!) until this
one. If you read the file and just sent the note on/velocity message,
the whole song would be over almost before you could hear the notes. In
addition to that, you would send all of the guitar notes in the song
before you sent even the first bass or drum note event. I know this
can't be right, so, is this timing "problem" being taken care of by the
Alsa driver? If not, where can I look in the code to see how you manage it.

Perhaps I've totally missed the point of what you're trying to do. I'm
also still having trouble understanding the hseq file format and what's
actually in it. Have you documented this yet? Maybe it's because of
where I'm looking at the process (very low level) and where you are
(just calling a driver that handles the MIDI timing and such) that makes
me think that a port to another system would be "easy." If we are
going to send note on/off messages and take care of the timing, the midi
port doesn't have to look like anything more than a serial port which
should be very easy to convert from system to to system.

Let me know what I'm missing here so I can start to get some real work done.

Again, Merry Christmas!!

len

Hello Len,

Good to hear there is some progress :) For sure it would be the best
idea to get it to work on Linux first (ask me in case of any trouble).
One more question: how are you going to get things compile on windows?
Are you going to use Makefiles? What is your 'compile environment'?

And as you still didn't answer (sorry, but that's quite important for
proper cooperation): How do you feel with using Bazaar? Are you
familiar with some version control systems? Are you able to use the
branch I started for the windows port?

When it comes to the driver: yes, lots of job is done for me. ALSA
does the whole timing. Thats really useful, because since ALSA is a
kernel module, it can for example process everything in realtime, or
use some forms of hardware acceleration, and because it cares for all
that job, I'd rather not take care about timing manually, when I can
send everything to ALSA. To understand better the basics of ALSA
sequencer interface, please spend a minute or two to skim through
http://www.alsa-project.org/alsa-doc/alsa-lib/seq.html . You can omit
the Subscription thing - the parts that are most significant are the
ones concerning Event Queues - harmonySEQ uses these queues for events
scheduling. And there is the whole timing magic hidden. You may also
want to look at http://www.suse.de/~mana/alsa090_howto.html - there
are some well-described examples of tiny MIDI applications, to
understand what queues are used for. I know this may be TOTALLY
unrelated, but since it's not clear for you how harmonySEQ uses ALSA's
interface, I recommend you to get familiar with these queues. (I
wonder whether there is any equivalent of event queues for Windows...
no idea.)

When it comes to the file format: It's not yet documented, but I do
have commented the source (the newest version is in trunk, please
confirm me whether you can obtain the newest code from the development
branch), which makes it much easier to understand. And I do call
something else: To save a file I just create an instance of
Glib::KeyFile, I put lots of data inside, it sorts and organizes it
into something similar to the .ini format, and then I export the data
from it to file - moreover, I hope nothing needs to be done for
windows, when it comes to saving the files.

In the development branch some files are already commented (including
the ones that deal with files), so have a look at them, unless you
already use the source from there. Now in some free time I'm going to
explain even more precisely what's going on in the MIDI driver (if I
remember well, only the header file is now commented well), so I'll
try to help you even more :)

Ask me in case of any further trouble! :)

Rafał Cieślak

I've added many explanations and comments for you to MidiDriver.cpp, please get it from the trunk.

I've added many explanations and comments for you to MidiDriver.cpp, please get it from the trunk.

Hello Len,

You've been idle for some time, and I didn't get any message from you. That's OK, though. I just want to ask whether you are still interested in this project. If you aren't, that's no problem, but just let me know, as I'd like to know if you gave up. But in case you are still interested, but, for example, didn't have time, please inform me that you still want to help me (0.14 recently released) :).
So please tell me what's your current status on harmonySEQ, no matter whether you are stil interested in this project's developement, or whether you abandoned it - I will respect your decision :)

Hello Rafal,

I'm very sorry that I've been so "quiet" lately. With all of the cold
weather we've had here, it's kept me extremely busy and hasn't left much
"playtime." I can assure you I'm still interested. I went so far as to
build a Linux server just for experimenting but I haven't had the chance
to do much more than get it going. I have found some other pieces of
Windows software that may work better for me and what I'm trying to do
but I am still going to try and get harmonySEQ going. Be patient with
me while I get through this winter!

len

On 2/7/2011 9:19 AM, Rafal Cieslak wrote:
> Your question #138111 on harmonySEQ changed:
> https://answers.launchpad.net/harmonyseq/+question/138111
>
> Rafal Cieslak posted a new comment:
> Hello Len,
>
> You've been idle for some time, and I didn't get any message from you. That's OK, though. I just want to ask whether you are still interested in this project. If you aren't, that's no problem, but just let me know, as I'd like to know if you gave up. But in case you are still interested, but, for example, didn't have time, please inform me that you still want to help me (0.14 recently released) :).
> So please tell me what's your current status on harmonySEQ, no matter whether you are stil interested in this project's developement, or whether you abandoned it - I will respect your decision :)
>

Good to hear from you. No worries, there is no need to hurry, so it's OK you don't have time (I also have much less time than I used to have). I do will be patient - I always am:)

Rafal

This question was expired because it remained in the 'Open' state without activity for the last 15 days.

Reverting automatic question's status change to expired.