Xaver Römer

I'm writing a midi-looper with a display for the push2 and the possibility to quantize events. For recording, playback and editing events I used [mtr] as an easy to use object. But I found some bugs and/or misbehaviour.

1) sending lots of cleareventat and addevent messages at the same time while mtr is running produces errors. mtr creates wrong events. so I started to use dicts. but:

2) sending dicts to mtr produces misbehaviour. on sending of a dict mtr starts from the beginning. if you use a workaround and try to set mtr by (playat $1) with the playposition from mtr_info, mtr's timing gets out of sync. At least when you send lots of dicts.

3) Sending many dicts in a short period to a running mtr, might crash max.

4) setting track length of mtr is inconsistent. setting longer intervals while mtr is running, works as expected. Setting shorter intervals, starts mtr from the beginning. seems to be normal buffer behaviour. But I expect a ready-to-use-object to work the same way on both messages.

5) mtr creates a dump_dict with nested lists and dicts. they can't be created by [dict] methods (at least I couldn't find a way), so one has to use js, which is too slow.

My excuses for not appending a patch. But after finishing the display for the push and the quantization, I'm quite frustrated on mtr's behaviour. So I started to write my own mtr object.

Here are the troubles I found:

1) sending lots of cleareventat and addevent messages at the same time while mtr is running produces errors. mtr creates wrong events. so I started to use dicts. but:

2) sending dicts to mtr produces misbehaviour. on sending of a dict mtr starts from the beginning. if you use a workaround and try to set mtr by (playat $1) with the playposition from mtr_info, mtr's timing gets out of sync. At least when you send lots of dicts.

3) Sending many dicts in a short period to a running mtr, might crash max.

My excuses for not appending a patch. But after finishing the display for the push and the quantization, I'm quite frustrated on mtr's behaviour. So I started to write my own mtr object. 

Hi,
I'm writing a midi-looper with a display for the push2 and the possibility to quantize events. For recording, playback and editing event

mtr-bugs-andor-inconsistencies

I noticed there was an update to mtr recently, did any of these bugs get worked out?

Sorry, as I wrote my own mtr-like object I didn't try max [mtr] anymore.

Sorry, as I wrote my own mtr-like  object I didn't try max [mtr] anymore.

mtr: bugs and/or inconsistencies