Matt Mower's dashboard

Hi demetrius.

I have just made a change that will, I think (I hope), resolve the problem for you. You will need to update your local copy of the git repository. I suspect you cloned my directly which means you should be able to "git pull" to get my changes. Try it and see.

M. – Matt Mower, on January 23, 2009 08:55

Thanks for the pointer. I did try and get this to work but couldn't figure out how to get Logic to act as a master. Whenever I tried to get this working it seemed that Logic wanted to slave itself to some external clock.

Some more learning to do here I think!

M. – Matt Mower, on January 21, 2009 10:01

Yep, I think probably this is the kind of thing we'll end up with. – Matt Mower, on January 21, 2009 09:59

The next release will include a preferences pane where you will be able to alter the layer thread priority and boost it to maximum. If you're already hitting CPU issues I am not confident this will solve your problems but it's a fairly easy place to start.

Octatone correctly identifies that each layer is sending MIDI independent of the others and this is not ideal. However the correct solution is to use CoreMIDI's forward scheduling linked to the tempo. If I can get the timing code into better shape and optimize the run loop this should work very nicely.

One issue is that boosting the priority of the layer threads might, in a worst case scenario, mess with the high priority thread driving the CoreMIDI server. So we might solve one problem and gain another.

We'll see :)

Regards,

Matt

p.s. Expect 0.9.4 in a couple of days all being well.

Hi demetrius.

Did you get round this problem with MMI's advice?

Do you have AIM/iChat or IRC? (IRC for pref, I'm sandbags in #logicstudio & #midi on Freenode IRC)

Matt – Matt Mower, on January 21, 2009 00:10

Hi Octatone.

I am aware of one crash bug that can occur when modifying "stuff" while the player is running. Can you take a look in:

~/Library/Logs/Crash Reporter/

for a file like:

Elysium_2009-01-18-173154_Siona.crash

the datetime & hostname will be different for yours but it should follow the same template.

Please add a ticket and attach the .crash file to it. I will take a look at it.

Okay guys I am persuaded that this should be a higher priority. At least to experiment with some of the more obvious possibilities.

There is already a "performance mode" setting in the player menu. Right now this just turns off the note-on-click functionality that can be annoying when you're working. I'll look at using it to also boost the layer thread priorities.

This would mean that, while you're experimenting, you could keep the UI prioritized but when you want to start recording you could turn performance mode on and the layers would get priority.

I don't know if this will work but we can try it out.

See this ticket for more details.

And thanks for all the feedback. It's very handy to get perspective from people who've been involved in music production for some time. I have about 5 months... still a neophyte :-)

Matt

Hi Demetrius.

That's great, thank you!

You're right the token graphics are drawn using Objective-C. I use the NSBezierPath class which has simple methods for drawing lines, arcs, rectangles and so forth.

The advantage for me was that I could figure it out and gradually achieve something without having to actually draw anything. Also it scales well with the layer graphics (which are also drawn with a NSBezierPath's).

I can post a chunk of the code to draw the tokens for you to look at if it would be helpful. Also here is the NSBezierPath documentation which shows the kinds of thing you can do with them, e.g.:



Is this the best way to draw the token graphics? I'm not sure. But there was no way I could draw vector icons any better that would scale.

Beyond the nuts and bolts of how they are drawn is "what" to draw. The icons aren't really very good in terms of representing what they do.

At the moment the tokens are:

• generate - spawns new playheads in a given direction


• note - plays a note when a playhead enters its cell


• rebound - redirects incoming playheads in a given direction


• absorb - absorbs playheads that enter its cell


• split - spawns new playheads in multiple directions when a playhead enters its cell


• spin - modifies the direction of generate and rebound tokens

there are also some new token types being thought about:

• tripwire - run a script when a playhead enters its cell


• trap - "traps" playheads entering its cell for some period of time


• wormhole - transports a playhead to a different layer

I haven't even begun to think what kind of icons those tokens will need.

I hope this gives you something to think about. I don't have a lot of experience of working with designers so I'm not entirely sure how to respond to your offer (other than to thank you for the kind offer :))

Let me know what you think.

m/

Hi Octatone.

I have opened a bug ticket for this problem:

http://lucidmac.lighthouseapp.com/pro...

I think you should be able to attach your file to this ticket. If not let me know.

Matt

Hi Octatone.

Thanks for the nice comment, I'm glad you're enjoying using Elysium.

Unfortunately timing is a weak area. As you have identified each layer runs on a separate thread. Accurate timing of threads is not easy to achieve (and I don't claim to have achieved it). There is also the UI running on the main thread.

An issue which needs to be solved at some point is that the MIDI timing is only loosely related to the beat. What I mean by this is that each layer thread basically sleeps to some point before the next beat, wakes up does it's thing and MIDI gets sent out along the way.

This is pretty fuzzy but, on a fast computer (and I didn't ask you what you were using), it works well enough for most purposes. But, as you start hitting your CPU limits, the threads don't have enough time to run and things get out of sync.

There are, broadly, two things that need to happen:

* Clean up/optimize the timing code
* Schedule MIDI to go out on the beat, across all layers

Both are on the list of things to do but I'm one person working in my spare time and it's a *big* list.

With respect to your specific problem of dropping tokens during play. Well in general it's an interaction between the high priority main thread that runs the UI and the background threads running the layers. If the layer thread wakes up a bit late it's MIDI goes out a bit late.

When I come to cleaning up the timing code I might look at using high priority threads for the layers. But I am afraid this would so starve the UI that we'd be mired in other problems.

All of which is a roundabout way of saying I have no answer for you. I agree it sucks that it doesn't work better. I hope in due course to fix it. But right now I don't know of any quick fix to make it better.

Matt.

Hi Octatone.

That's an unusual problem to be sure, thanks for letting me know about it.

In order to help me try and reproduce it would be helpful to know a little more about the symptoms:

Have you noticed any kind of pattern to when it will or won't popup? Is it related to any specific kind of oscillator perhaps? Does it always happen in any composition? Or only for specific compositions?

If the button stops working on one parameter does it also stop working for other parameters? Or can you still add/edit oscillators to those?

Hopefully we can track this down together and I can fix it.

Matt

Hi Demetrius.

Your offer of help is most welcome, thank you. However it's not the Elysium logo that I was asking for help with but, rather, the icons drawn onto cells to represent the various tokens such as generators, notes, splitters and so forth.

These were some of the first graphical elements I did and really display my lack of affinity for that kind of work. I think that both the symbols and the way they are drawn could do with rethinking.

If you're still interested in helping I'd be happy to explain further.

Thanks,

Matt

Hi amounra.

I'd be very grateful for your help. In fact I think you've already helped with your description of how you implemented your tiction sequencer.

So, instead of running my own timing system and simply letting Logic/Live start & stop Elysium I could turn over the whole timing to the DAW and simply wait on event arriving.

There is one complication in that Elysium's layers can have independent tempo. That might still be supportable in a limited fashion by having Logic drive the maximum tempo and allowing layers to use slower tempos (e.g. host/2, host/3, etc..).

Do you have any code I can look at? Even if it's not directly translatable it might be interesting to understand it in overview.

Thanks,

m/ – Matt Mower, on January 14, 2009 08:50

Yep the issues will be the same with Live I think.

I haven't really had time to look into this further. I'm hoping that someone with a deeper understanding of the issues will pop up and offer some guidance. – Matt Mower, on January 09, 2009 11:29

Hi.

I don't have any hardware synths myself so I can't speak directly to this but I do know that Giles Bowkett was able to get it working with his Korg hardware:

http://gilesbowkett.blogspot.com/2008...

Elysium uses standard CoreMIDI to send so I don't *think* that there is anything special that you need to do to make it work. If you have Snoize software's MIDIMonitor app (very useful utility):

http://www.snoize.com/MIDIMonitor/

You may be able to compare say a keyboard that is working and Elysium that is not and see what's wrong. Maybe you can pin the problem down that way?

MMI.

Thanks for the suggestions.

1) At the moment rhythm (in terms of generating playheads) is restricted to the pulse count and probability. You could increase the complexity of what you can do right now using scripts but that's probably pretty heavyweight. I'd like to make it easier to come up with complex rhythmic patterns.

2) I hope this is covered by http://lucidmac.lighthouseapp.com/pro...

3) You could *probably* script that now using a willRun callback... maybe... however I plan to add a 'tripwire' token that would make this trivial, see http://lucidmac.lighthouseapp.com/pro...

4) I'm not quite sure how this would work but I think it could be done with scripts. I'll have to think about it a bit more :)

I'm really interested in improving the ability to experiment with rhymn keep the suggestions coming.

m/

The save/load code is a weak area in general.

I went with a custom XML based solution rather than using CoreData to try and promote the ability to share Elysium documents but that means I have a lot of custom code to save and load all the various elements and some of it is tricky.

I'm kind of surprised an old document would load. I must not have bumped the version number properly (it usually just says "no can do amigo"). In the short term you could either tinker by hand (save a working file and see what's different) or, resign yourself to recreating those files.

In the longer term I will make an effort, pre-1.0, to make save/load more robust.

Sorry that you've been hit by this.

Matt.

A quick note to say that some of these are implemented in version 0.9.0 released last night. Check the release notes in Sparkle for more details.

M.

More info:

• Improve token sigils filed as Ticket 40


• Keyboard shortcuts filed as Ticket 14 (in progress)


• Cell multiselect & operations filed as Ticket 11


• Preferences (including new document at startup) filed as Ticket 28

Hi.

Thanks for getting in touch and glad you like the app.

I've actually thought about this a little already and it's filed in our feature tracker if you to take a look and (I think you can) keep track of when it gets implemented.

Please feel free to make any further suggestions as you go along. I'm keen to hear how people would like to see Elysium develop and improve.

Matt