On Sat, Sep 20, 2003 at 01:05:29PM -0700, Miller Puckette wrote:

Yep, this is apparently a Bug, which has been present in every version of Pd and probably some versions of Max too.

Pd's MIDI parser just ignores everything starting with F0 or higher. (I thought I was dealing with sysex but, having just looked at the code, it looks like I forgot to put that in.)

I'm willing to try to fix this... but I can't really test it since I don't have any gear that spits out messages like that.

How about using the v_midi kernel module? You could pipe the output into another program which can print midi messages.

Chris.

On Sat, Sep 20, 2003 at 11:14:01AM -0400, Larry Troxler wrote:

...

(Sorry if this has been sent more then once)

Well, I haven't heard from anyone, and I don't see anything later than what I have that's relevant in CVS, so, I assume that no news is bad news, and that the PD MIDI parser vomits green blood when you send it Song Position Pointer messages.

... so I guess if you want something done, you gotta do it yourself.

So:

How are bug fixes submitted? (since the midi parser trips and falls when getting an $F2, screwing up for example, the notein object, this isn't just a missing feature, it's a bug)

I suppose I'll also have to make a MIDI object that sends a float when it receives a song position pointer (this I need). And also one that can send song position pointer messages (this I don't need, but I guess I gotta submit anyway for the sake of completeness - grumble grumble).

So, can someone suggest that best procedure who to send it to, in what format, should I put it in the CVS directly, post patch files, send to Miller, etc...?

But honestly, it would motivate me greatly to do a complete and thorough job, if someone would send me some pointers or URLs on how to deal with this hard-tab issue. It seems that the source I got from CVS has actual hard tabs in it, and so far I don't see anything in the CVS docs on how to bypass that so I get a clean copy, nor any mention anywhere in the source files of what the spacing that these hard tabs represent. I truly wish people would stop using these retarded things, but since they still insist, I need advice on how to deal with these "legacy" files.

Larry

---

PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev

---

PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev

On Monday 22 September 2003 06:00, Krzysztof Czaja wrote:

hi Larry,

in (x)emacs you would just hook (untabify (point-min) (point-max)) after (set-variable 'tab-width 8) on c-mode-common, or type ``M-x untabify'' on a selected buffer. There is expand as well, on any unix.

Thanks, actually that tip will help a lot (but what happens with CVS - does it know to consider tabs equivalent to spaces, and if so, how does it know what the tab spacing is?

One thing I learned here (I think) is that normally hard tabs are eight spaces on Unix. At least that seems to be the first spacing to try.

Btw, I happen to prefer the `legacy' way...

Krzysztof

Well, you're welcome to try to rationalize that preference - I'd really like to know why you like hard tabs better :-)

Larry

On Saturday 27 September 2003 05:16, Frank Barknecht wrote:

As a tab is just one character and not 8 or 2 or 4, there is no "rule" on Unix that it is eight spaces normally. The eight character thing is just the width, some editors like to show a tab.

Personally I set the tabwidth in Vim to 4 because 8 is much to wide for my tastes. But someone else wouldn't know this, it makes no difference when using real tabs like "\t".

Using expaned tabs everyone would see 4 spaces for indenting in my code and would have to live with it. That's one of the reasons I prefer \t-tabs in my code, the other is faster navigation (faster moving over less characters).

In Pd or any C language this is really no problem at all, but I do program a lot in Python, and here a community project has to agree on one single indentation/tab style.

ciao

Frank, what you're describing is how tab characters are intended to be used. The problem is that all too often, they are used incorrectly; sometimes both tabs and spaces are used for indentation, or a tab character is used to indent to a specific character position. In these cases, I'm forced to try different tab spacings until I find the "right" one.

Larry

On Saturday 27 September 2003 15:03, Frank Barknecht wrote:

Hallo,

Larry Troxler hat gesagt: // Larry Troxler wrote:

...

Frank, what you're describing is how tab characters are intended to be used. The problem is that all too often, they are used incorrectly; sometimes both tabs and spaces are used for indentation, or a tab character is used to indent to a specific character position. In these cases, I'm forced to try different tab spacings until I find the "right" one.

Ah, okay. Now I understand. So the tabs aren't the problem, the mixing of tabs and spaces is, because everyone and their sisters use differnet expansion widths.

Yes!

To avoid alignment problems between people who have tabs set to different widths. A common use of tabs is to align the values of a dictionary or the right hand sides of several consecutive assignment statements. There is no problem when using tabs for indentation, but when they are used past non-tab characters, the alignment will be skewed when the tab width is changed (e.g., when a different developer with a different tab width views the code).

Yes again! Someone understands me!

Maybe I'm not going crazy after all. Well, I probably still am going crazy ...

In C it's more a cosmetic issue. CVS I think doesn't do anything about it: spaces stay spaces and tabs are tabs in the repository.

ciao

Not good, but I guess that's ok. It's more important that "patch" and "diff" have options to ignore whitespace. I haven't checked yet.

We now return you to your regular programming (maybe)

Larry

On Saturday 27 September 2003 16:51, Frank Barknecht wrote:

Hallo,

Larry Troxler hat gesagt: // Larry Troxler wrote:

...

Not good, but I guess that's ok. It's more important that "patch" and "diff" have options to ignore whitespace. I haven't checked yet.

Yes:

diff: -b --ignore-space-change Ignore changes in the amount of white space. -w --ignore-all-space Ignore all white space.

patch: -l --ignore-whitespace Ignore white space changes between patch and input.

ciao

Thanks Frank, but hopefully you didn't spend a lot of time doing my "homework" for me - I was planning to check this out later on my own.

Thanks, though :-)

Larry

Hallo, Miller Puckette hat gesagt: // Miller Puckette wrote:

Just to throw in my own 2 cents... The Pd sources are: tabs 8 spaces (their historical value), indentation 4 spaces. This unfortunately means that Pd does mix spaces and tabs for indentation. However, there's no rule that says that Pd source files have to use tabs at all; the indentation may be implemented using all spaces. However, I haven't set my own text editor to avoid tabs. Most text editors will at least allow you to set tab to 8 spaces, although some of them then assume that of course you want to indent 8 spaces too, which is inappropriate for Pd code, since I also adhere to a limit of 80 columns.

I also feel, that indenting 8 visible spaces is too wide. I normally use tabs everywhere, but let them appear in my editor (Vim) 4 spaces wide. It's enlightening to read, what the Vim docs say about this: (tabstop is width of tab, shiftwidth is indent width)

There are four main ways to use tabs in Vim: 1. Always keep 'tabstop' at 8, set 'softtabstop' and 'shiftwidth' to 4 (or 3 or whatever you prefer) and use 'noexpandtab'. Then Vim will use a mix of tabs and spaces, but typing Tab and BS will behave like a tab appears every 4 (or 3) characters. 2. Set 'tabstop' and 'shiftwidth' to whatever you prefer and use 'expandtab'. This way you will always insert spaces. The formatting will never be messed up when 'tabstop' is changed. 3. Set 'tabstop' and 'shiftwidth' to whatever you prefer and use a |modeline| to set these values when editing the file again. Only works when using Vim to edit the file. 4. Always set 'tabstop' and 'shiftwidth' to the same value, and 'noexpandtab'. This should then work (for initial indents only) for any tabstop setting that people use. It might be nice to have tabs after the first non-blank inserted as spaces if you do this though. Otherwise aligned comments will be wrong when 'tabstop' is changed.

You use 1, I use 4., 2. will work everywhere, 3. only in Vim. Duh!

ciao