Re: [PD] including bpm info to midi-recording

[Jakob Laue]

Hey Martin,

thanks for your hints!

 

I created a midi file in ableton, exported it and then read it with the midifile-read-help-patch. 

This is what I get after reading:

 


midifile: opened /Users/wbjc/Desktop/ableton.mid
midifile: Header chunk type: MThd
midifile: Header chunk length: 6
midifile: Header chunk format: 0 (Single multichannel track)
midifile: Header chunk ntrks: 1
midifile: Header chunk division: 0x60: 96 ticks per quarter note
midifile: Track chunk 0 type: MTrk, length 81

 

 

 

And this is what I get after the |dump 0( message:

 

 

 


midifile: Parsing track[0]...
midifile: tick 0 delta 0 status FF Meta 0x03 length 1 
Sequence/Track Name 
midifile: tick 0 delta 0 status FF Meta 0x58 length 4 
Time Signature 4/4 36 clocks per tick, 8 32nd notes per quarter note
midifile: tick 0 delta 0 status FF Meta 0x58 length 4 
Time Signature 4/4 36 clocks per tick, 8 32nd notes per quarter note
midifile: tick 0 delta 0 status 90 MIDI 0x90 42 64 : channel 1 Note 66 On velocity 100
midifile: tick 24 delta 24 status 80 MIDI 0x80 42 40 : channel 1 Note 66 Off velocity 64
midifile: tick 72 delta 48 status 90 MIDI 0x90 41 64 : channel 1 Note 65 On velocity 100
midifile: tick 96 delta 24 status 80 MIDI 0x80 41 40 : channel 1 Note 65 Off velocity 64
midifile: tick 120 delta 24 status 90 MIDI 0x90 46 64 : channel 1 Note 70 On velocity 100
midifile: tick 144 delta 24 status 80 MIDI 0x80 46 40 : channel 1 Note 70 Off velocity 64
midifile: tick 168 delta 24 status 90 MIDI 0x90 41 64 : channel 1 Note 65 On velocity 100
midifile: tick 192 delta 24 status 80 MIDI 0x80 41 40 : channel 1 Note 65 Off velocity 64
midifile: tick 216 delta 24 status 90 MIDI 0x90 40 64 : channel 1 Note 64 On velocity 100
midifile: tick 240 delta 24 status 80 MIDI 0x80 40 40 : channel 1 Note 64 Off velocity 64
midifile: tick 264 delta 24 status 90 MIDI 0x90 45 64 : channel 1 Note 69 On velocity 100
midifile: tick 288 delta 24 status 80 MIDI 0x80 45 40 : channel 1 Note 69 Off velocity 64
midifile: tick 312 delta 24 status 90 MIDI 0x90 41 64 : channel 1 Note 65 On velocity 100
midifile: tick 336 delta 24 status 80 MIDI 0x80 41 40 : channel 1 Note 65 Off velocity 64
midifile: tick 336 delta 0 status FF Meta 0x2F length 0 
End of Track 0==


 

 

 

The differences that I noticed:

 

In the ableton-file the "header chunk division" is given as "ticks per quarter note", whereas in the midifile-file it is given in "frames per second and ticks per frame".

 

 

 

midifile: Header chunk division: "0x60: 96 ticks per quarter note"

midifile: Header chunk division: "0xE714: 25 frames per second, 20 ticks per frame"

 

 

In the ableton-file there is an info given about the time signature: "Time Signature 4/4 36 clocks per tick, 8 32nd notes per quarter note"

 

This info is not present after loading the file that i recorded with [midifile].



 

 

Furthermore, looking at the first lines of the dump-info of the ableton-exported-file, we can see that there is also one note being played at tick 0, but I did not actually put a note there. The same applies for the [midifile]-recorded file. I did not play notes directly after hitting the record-[bang]. I don't know how these notes on the first tick (0) have gotten there.

 

As a side-note the help-patches that I am using are from 2010 (write-help-patch) and 2011 (read-help-patch). These were included in the mrpeach_v0-0-extended package that I downloaded via deken.

 

Best, Jakob

 

 


Gesendet: Sonntag, 05. April 2020 um 17:28 Uhr
Von: "Martin Peach" 
An: "Jakob Laue" 
Cc: Pd-List 
Betreff: Re: Re: Re: Re: [PD] including bpm info to midi-recording

On Sun, Apr 5, 2020 at 9:48 AM Jakob Laue  wrote:
>
> Hey Martin,
> I tried again today. I recorded a new midi file and then loaded it with the midifile-read-help-patch.
>
> After loading the file I get:
>
> midifile: opened /Users/wbjc/Desktop/mpxy.mid
> midifile: Header chunk type: MThd
> midifile: Header chunk length: 6
> midifile: Header chunk format: 0 (Single multichannel track)
> midifile: Header chunk ntrks: 1
> midifile: Header chunk division: 0xE714: 25 frames per second, 20 ticks per frame
> other_meta: frames_per_sec 25
> other_meta: ticks_per_frame 20
> midifile: Track chunk 0 type: MTrk, length 432
>
>
> And then if I send a |dump 0( message to [midifile] I get:
>
> midifile: Parsing track[0]...
> midifile: tick 0 delta 0 status 99 MIDI 0x99 24 60 : channel 10 Note 36 On velocity 96
> midifile: tick 0 delta 0 status 89 MIDI 0x89 24 00 : channel 10 Note 36 Off velocity 0
> midifile: tick 0 delta 0 status 99 MIDI 0x99 2B 65 : channel 10 Note 43 On velocity 101
> midifile: tick 0 delta 0 status 89 MIDI 0x89 2B 00 : channel 10 Note 43 Off velocity 0
> midifile: tick 0 delta 0 status 99 MIDI 0x99 2B 7F : channel 10 Note 43 On velocity 127
> midifile: tick 0 delta 0 status 89 MIDI 0x89 2B 00 : channel 10 Note 43 Off velocity 0
> midifile: tick 0 delta 0 status 99 MIDI 0x99 25 72 : channel 10 Note 37 On velocity

Re: [PD] Number Boxes, Sliders, Symbols - strange behavior (no graphic update)

[Jean-Marie Adrien]

Hi
got some problems myself from time to time with GUI elements poorly updating 
when pd has a very big CPU load, zb several instances of pd running at 60 
percent each, developing all day on same patch while running... 
solution : simplify the patch (remove unnecessary GUI elements) or at least 
quit and relaunch
JM

> Le 6 avr. 2020 à 04:33, Ingo  a écrit :
> 
> Hi there,
>  
> I'm on Debian 32-bit with Pd 0.49.
> I'm experiencing all the sudden a strange behavior with number boxes, sliders 
> and symbols.
> They are sending values when I click and move the mouse but their graphics do 
> not get updated.
>  
> I. e. I can change the value on the output of a number box but its graphics 
> are not updated anymore.
> If I connect
>  
> [prepend set]
>   |
> [  (
>  
> I can see the values but the number box itself keeps displaying "0".
>  
> When I open the properties of the number box and press Apply or OK the value 
> will be updated to the latest value but then stay there as far as displaying 
> goes. Still sending and receiving without any graphical update.
>  
> Does anybody have an idea what is happening and how I can fix this issue?
>  
> Thanks!
> Ingo
> ___
> Pd-list@lists.iem.at  mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list 
> 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Number Boxes, Sliders, Symbols - strange behavior (no graphic update)

[Ingo]

Thanks for the suggestion, Jean-Marie! That's not an option, though!

 

I have been working on this patch for more than 10 years fulltime by now.

The graphical editor can already be turned on or off for optimized playing.

But the patches still need to be editable.

 

It's runnung perfectly on the machine that I use for programming which is the 
identical hardware as the other units that I'm using.

Sometimes it works and sometimes it doesn't. All other graphical objects except 
the ones mentioned plus the graphical array are working fine.

 

By now I'm suspecting some currupted files on the OS.

The first thing I'd like to check is the TCL/TK files.

 

I need to know where the files (all files) are located and replace them from a 
system that doesn't show those issues.

The problem is that I have over one hundred of these boxes out there - all over 
the world …
Building a new operating system and making a new image is an option.

However, many people have trouble with creating an image (even though it is 
fully automated).

 

Ingo

 

 

From: Jean-Marie Adrien [mailto:jm.adrien@gmail.com] 
Sent: Monday, April 06, 2020 10:00 AM
To: Ingo
Cc: Pd-List
Subject: Re: [PD] Number Boxes, Sliders, Symbols - strange behavior (no graphic 
update)

 

Hi

got some problems myself from time to time with GUI elements poorly updating 
when pd has a very big CPU load, zb several instances of pd running at 60 
percent each, developing all day on same patch while running... 

solution : simplify the patch (remove unnecessary GUI elements) or at least 
quit and relaunch

JM

 

Le 6 avr. 2020 à 04:33, Ingo mailto:i...@miamiwave.com> > 
a écrit :

 

Hi there,

 

I'm on Debian 32-bit with Pd 0.49.

I'm experiencing all the sudden a strange behavior with number boxes, sliders 
and symbols.

They are sending values when I click and move the mouse but their graphics do 
not get updated.

 

I. e. I can change the value on the output of a number box but its graphics are 
not updated anymore.

If I connect

 

[prepend set]

  |

[  (

 

I can see the values but the number box itself keeps displaying "0".

 

When I open the properties of the number box and press Apply or OK the value 
will be updated to the latest value but then stay there as far as displaying 
goes. Still sending and receiving without any graphical update.

 

Does anybody have an idea what is happening and how I can fix this issue?

 

Thanks!

Ingo

___
  Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->  
 
https://lists.puredata.info/listinfo/pd-list

 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] MIDI 2.0

[Mario Buoninfante]

Hi all,

Is there any plan to support MIDI 2.0? I know this is more of a question
about PortMidi, but I was wondering if anybody knows anything about it.

Cheers,
Mario
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI 2.0

[Dan Wilcox]

Actually, form what I've read, I don't think MIDI 2 requires any (or very many) 
changes to Portmidi as Portmidi wraps the various OS-level MIDI APIs and gives 
you raw bytes. The actual MIDI protocol interpretation is handled in the Pd 
core.

MIDI 2 is basically an extension of the MIDI 1 protocol and MIDI 2 messages can 
contained embedded MIDI 1 messages. There is an additional query communication 
where a device can ask about the capabilities of another device. Overall, it 
seems to be designed to work seamlessly with older MIDI 1 devices/software.

Short answer is: I don't think anyone is doing this, but it can probably been 
done by modifying MIDI handling in s_midi.c.

> On Apr 6, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
> 
> Message: 1
> Date: Mon, 6 Apr 2020 10:51:26 +0100
> From: Mario Buoninfante  >
> To: pd-list mailto:pd-list@lists.iem.at>>
> Subject: [PD] MIDI 2.0
> Message-ID:
>>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi all,
> 
> Is there any plan to support MIDI 2.0? I know this is more of a question
> about PortMidi, but I was wondering if anybody knows anything about it.
> 
> Cheers,
> Mario


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI 2.0

[Mario Buoninfante]

Hi Dan,

Thanks for getting back to me.
Yap, I had a look at the protocol and is like you said about
retro-compatibility.
I'm glad to hear that probably can be dealt with making some changes in
s_midi.c, work that of course I know still takes some efforts.
My question though, was more related to the new msg introduced by MIDI 2.0,
with a different structure and resolution.
But I suspect what you said is valid for that as well, right?

Cheers,
Mario


On Mon, 6 Apr 2020 at 14:23, Dan Wilcox  wrote:

> Actually, form what I've read, I don't think MIDI 2 requires any (or very
> many) changes to Portmidi as Portmidi wraps the various OS-level MIDI APIs
> and gives you raw bytes. The actual MIDI protocol interpretation is handled
> in the Pd core.
>
> MIDI 2 is basically an extension of the MIDI 1 protocol and MIDI 2
> messages can contained embedded MIDI 1 messages. There is an additional
> query communication where a device can ask about the capabilities of
> another device. Overall, it seems to be designed to work seamlessly with
> older MIDI 1 devices/software.
>
> Short answer is: I don't think anyone is doing this, but it can probably
> been done by modifying MIDI handling in s_midi.c.
>
> On Apr 6, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at wrote:
>
> Message: 1
> Date: Mon, 6 Apr 2020 10:51:26 +0100
> From: Mario Buoninfante 
> To: pd-list 
> Subject: [PD] MIDI 2.0
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> Is there any plan to support MIDI 2.0? I know this is more of a question
> about PortMidi, but I was wondering if anybody knows anything about it.
>
> Cheers,
> Mario
>
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
>
>
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] MIDI 2.0

[Dan Wilcox]

Mmm my initial thought is that the existing objects can simply send out a more 
finer grained number. Design-wise, I think we would want to utilize as many of 
the existing objects as possible, ie. input/output MIDI 2 range, maybe add 
messages or creation args for special MIDI 2 modes. This could also require 
some sort of new object as well. The best design would not affect patching 
between MIDI 1 and MIDI 2, if possible.

For now, though, I think MIDI 2 could be implemented at the patch level using 
the raw MIDI bytes from [midiin] and [midiout]. It would probably take some 
doing, but MIDI 1/2 are basically just raw bytes and the notion, ctlin, etc 
objects a result of interpreting the protocol.

> On Apr 6, 2020, at 4:14 PM, Mario Buoninfante  
> wrote:
> 
> Hi Dan,
> 
> Thanks for getting back to me.
> Yap, I had a look at the protocol and is like you said about 
> retro-compatibility. 
> I'm glad to hear that probably can be dealt with making some changes in 
> s_midi.c, work that of course I know still takes some efforts.
> My question though, was more related to the new msg introduced by MIDI 2.0, 
> with a different structure and resolution.
> But I suspect what you said is valid for that as well, right?
> 
> Cheers,
> Mario
> 
> 
> On Mon, 6 Apr 2020 at 14:23, Dan Wilcox  > wrote:
> Actually, form what I've read, I don't think MIDI 2 requires any (or very 
> many) changes to Portmidi as Portmidi wraps the various OS-level MIDI APIs 
> and gives you raw bytes. The actual MIDI protocol interpretation is handled 
> in the Pd core.
> 
> MIDI 2 is basically an extension of the MIDI 1 protocol and MIDI 2 messages 
> can contained embedded MIDI 1 messages. There is an additional query 
> communication where a device can ask about the capabilities of another 
> device. Overall, it seems to be designed to work seamlessly with older MIDI 1 
> devices/software.
> 
> Short answer is: I don't think anyone is doing this, but it can probably been 
> done by modifying MIDI handling in s_midi.c.
> 
>> On Apr 6, 2020, at 12:00 PM, pd-list-requ...@lists.iem.at 
>>  wrote:
>> 
>> Message: 1
>> Date: Mon, 6 Apr 2020 10:51:26 +0100
>> From: Mario Buoninfante > >
>> To: pd-list mailto:pd-list@lists.iem.at>>
>> Subject: [PD] MIDI 2.0
>> Message-ID:
>>  > >
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Hi all,
>> 
>> Is there any plan to support MIDI 2.0? I know this is more of a question
>> about PortMidi, but I was wondering if anybody knows anything about it.
>> 
>> Cheers,
>> Mario
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list