Re: [PD] linux aliases files disappear when uncompressing in macOS

[IOhannes m zmölnig]

Am 5. Oktober 2020 02:59:35 MESZ schrieb Alexandre Torres Porres 
:
> 
> any hint?
> 



macOS filesystems (hfs+), are case-insensitive by default.
that is: you can open the file "foo.txt" as "FoO.TXt" and vice-versa.
as a consequence these two names refer to the identical file.
so if you have a zip-file containing both, they will overwrite themselves.

solution: use a case-sensitive filesystem.


mfg.hft.fsl
IOhannes

mfg.hft.fsl
IOhannes


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

Re: [PD] linux aliases files disappear when uncompressing in macOS

[IOhannes m zmölnig]

Am 5. Oktober 2020 02:59:35 MESZ schrieb Alexandre Torres Porres 
:
> 
> any hint?
> 



macOS filesystems (hfs+), are case-insensitive by default.
that is: you can open the file "foo.txt" as "FoO.TXt" and vice-versa.
as a consequence these two names refer to the identical file.
so if you have a zip-file containing both, they will overwrite themselves.

solution: use a case-sensitive filesystem.


mfg.hft.fsl
IOhannes


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

[PD] linux aliases files disappear when uncompressing in macOS

[Alexandre Torres Porres]

Hi, I have a problem with aliases in Linux for objects like cyclone's Uzi -
for instance, we have uzi and Uzi is just an alias. These aliases are
generated just fine and you can see them here on github
https://github.com/porres/pd-cyclone/releases/download/cyclone_0.5-3/cyclone_0.5-3_Linux64.tar.gz

The problem is if I unzio this in macOS, as the aliases don't show and
disappear, and since I'm uploading to deken via macOS, they're not there. I
guess there's the solution of uploading via linux and some other workaround
but I was wondering if there's a way to make it work and decompress these
files in macOS.

any hint?

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

Re: [PD] mrpeach/midifile: multiple voices

[Jakob Laue]

Hey Martin,
I tried altering the midi channel number and it works!

I want to thank you very much for your quick help because i am currently in the 
(in Germany we say) "hot phase" of implementing software for my master thesis. 
And unexpected time consuming things are something that i really cant afford 
right now, so indeed you helped me a lot to get my stuff done:)))

Best, Jakob 
 
 
 

Gesendet: Sonntag, 04. Oktober 2020 um 03:02 Uhr
Von: "Martin Peach" 
An: "Jakob Laue" 
Cc: "Pd-List" 
Betreff: Re: Re: [PD] mrpeach/midifile: multiple voices
On Sat, Oct 3, 2020 at 7:15 PM Jakob Laue  wrote:
>
>
> Hi Martin,
> thanks for your quick response!
>
>
>
>
>
> Gesendet: Samstag, 03. Oktober 2020 um 19:02 Uhr
> Von: "Martin Peach" 
> An: "Jakob Laue" 
> Cc: "Pd-List" 
> Betreff: Re: [PD] mrpeach/midifile: multiple voices
> On Sat, Oct 3, 2020 at 7:05 AM Jakob Laue  wrote:
> >
> > Hi list,
> > i have a patch that a melody and saves it into a midifile with [midifile] 
> > from mrpeach.
> > Now i have extended the patch so that there is a second melody generated 
> > which accompanies the first one. Now i also send the pitch/noteduration 
> > pair of the second melody to the same [midifile] object in order to receive 
> > a two-voice-midi-file. But unfortunately both melodies seem to overwrite 
> > their noteDurations and hence i have wrong note durations in the midi file.
> >
>
>
>
> Are you writing a single track with two MIDI channels or two tracks?
>
> ->> to be honest, I can not answer this question. I initialize [midifile] 
> with ...
> - filename and fps in one message
> - time signature message [255 88 4 4 2 38 8)
> - tempo message [255 81 ...(
> ...before I send it events.
>

If the events for the two melodies are in two different MIDI channels
it should work to record them in the default single track. So if you
add the channel number minus one to the MIDI status byte (for example,
144 is note-on status for channel 1, 145 is note-on in channel 2) they
should stay separate.


>
> If you use a [track ( message before each event it should keep them separate.
>
>
> -> Do you mean a track name message like "FF 03 len text Sequence/Track Name" 
> according to 
> http://www.music.mcgill.ca/~ich/classes/mumt306/StandardMIDIfileformat.html 
> at the bottom?
>

No. See under 2.2 - MIDI File Formats 0,1 and 2.
It's possible to make a multitrack midi file by sending, say, [track
2( to [midifile] before sending an event for track 2, then [track 1(
before a track 1 event. That way you could have several separate
instruments on the same MIDI channel. (This format 1 only writes
correctly in the latest midifile v.041, but all versions should be
able to read any format). Most of the midi files on the web seem to
have one instrument per track, and MIDI channel numbers are not used.
To use [midifile] as a sequencer it's easier to have one track and
several channels. To export a composition as a MIDI file, it should
probably be using several tracks.

Martin



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

Re: [PD] Concatenating two atoms into one?

[Maximiliano Estudies]

To add to the great explanations already given by Johannes and Christoph,
Miller gave a seminar last spring quarter called "Inside Pd" where he
explains the inner workings of Pd in great detail.
Here is the course site:
http://msp.ucsd.edu/syllabi/206.20s/index.htm
and here the videos:
http://msp.ucsd.edu/syllabi/206.20s/movies/
In the video 2b.apr10.mp4
 he explains the
symbol storage strategy.

I'm very grateful to be able to access this content, thank you Miller!

El jue., 1 oct. 2020 a las 13:21, Christof Ressi ()
escribió:

> > your computer memory will define the time when it will crash Pd (it will
> > crash, when all the strings in the symboltable eat up all the memory
> > available)
> I think eating up all available memory is not a likely scenario on
> modern computers with a 64-bit address space and virtual memory.
>
> The actual problem is that Pd's symbol table is implemented as a hash
> table with seperate chaining
> (https://en.wikipedia.org/wiki/Hash_table#Separate_chaining). This means
> that symbols which have the same hash value (= hash collision) are
> connected as a linked list. If you look up a such a symbol, you have to
> walk the linked list and do a string comparison for each element until
> you find a match.
>
> The more symbols you add, the more hash collisions you get and the more
> symbols end up in the same bucket. In practice, this means that for a
> large number of elements, insertion and lookup becomes more and more
> expensive because the linked lists for each bucket grow larger and
> larger. While the hash lookup takes constant time "O(1)", the linked
> list traversal takes linear time "O(N)" (and is not very cache friendly).
>
> Good hash table implementations mitigate this problems by a technique
> called "rehashing" where the hash table array is resized if the "load
> factor" (number of elements / number of buckets) exceed a certain
> threshold (= "load factor"). Then every item is hashed again and
> inserted back into the new hash table.
>
> Unfortunately, Pd doesn't do any rehashing and it is certainly possible
> to significantly slow down Pd by flooding the symbol table. A common
> load factor threshold is 0.75, but if you create 10 000 unique symbols
> in Pd, the load factor would be ~10! Not very good...
>
> In fact, I've already been thinking about improving the symbol table.
>
> Christof
>
> On 01.10.2020 10:28, IOhannes m zmoelnig wrote:
> > On 2020-10-01 09:54, oliver wrote:
> >> IOhannes m zmoelnig wrote:
> >>> On 2020-10-01 09:22, hans w. koch wrote:
>  but be aware of the risks of invoking makefilname all too often.
> >>> note that if you use dollsyms (as in `[$1$2(`) you are filling up the
> >>> symbol table just as well.
> >> i was just about to ask, if the attached modified patch would avoid that
> >> problem, but you replied already.
> >>
> >> could you please clarify the used term "invoke" a bit ?
> >> i guess the number of [makefilename] objects isn't the problem, but how
> >> much/often its conversion mechanism is used, right ?
> > yes (the latter).
> >
> >> does that mean that everytime a number->symbol conversion happens
> >> (regardless how it is done) the symboltable is filled and will
> > no.
> > everytime a *new* symbol is created.
> > the point of symbols (vs ordinary strings) is, that a single literal
> > only needs to be stored once.
> > so if you first create a string "rubadub" (however you do this), a new
> > entry for the symbol 'rubadub' is created.
> > now, if you concatenate the symbols 'rubad' and 'ub', the result is
> > "rubadub", which already happens to be in the symbol table (and thus no
> > new entry needs to be generated).
> > for Pd these strings are *identical*.
> > this is cool as we can really easily compare the two strings. if they
> > occupy the same entry in the symbol table (which basically means, that
> > Pd gets the same pointer for when turning the literal into a symbol),
> > then the two strings are the same.
> > so rather than having to compare each character of the string
> > "sjfdjdasjfsfjrueincru057894_curtrfenr3ewf8354j3wp57jp3" with each
> > character of "sjfdjdasjfsfjrueincru057894_curtrfenr3ewfB354j3wp57jp3" ,
> > Pd only needs to compare two pointers - and this can be done in a single
> > step on your CPU.
> >
> > the problem with generating symbol programmatically (e.g. by sending
> > numbers to [makefilename %d]) is, that it is so super easy to generate
> > lots and lots of (different) symbols.
> >
> >
> >> eventually slow down or crash PD ?
> >>
> >> so, as a live example: writing number values to GUI labels dynamically
> >> is a potentially dangerous thing ? what's the threshold there ?
> > your computer memory will define the time when it will crash Pd (it will
> > crash, when all the strings in the symboltable eat up all the memory
> > available)
> >
> > as for the slow-down, why not simply create a patch that tests this for
> you?
> >
> >