FRid

I think i may have found a bug or at least some very weird behaviour using the [text]-object. Decided to give this a new thread because it might be overlooked otherwise. Anyway if you want to know the history this discussion led to the discovery:

https://cycling74.com/forums/max-patch-to-destroy-jpeg-data

I'm using the filein to load 7000+ ints into [text]. This is all working fine except when i wish to dump these ints for further processing then values get lost. I've used another [text] to capture the output.

Any help is ofcourse greatly appreciated!

text-bug

anyone of the max team?
is there a limit when passing lists?


As for as i know (list-)limits are gone since max5 but i don't know for sure. And indeed i was also hoping someone from the max-team spotted this (or anyone else who knows about it).

This patch can be brought back to essentials like this. Note by the way that the last number in the text object is 10, which represents the first two digits of the value 1041.

To work around this limitation anyway, you could use a counter and induce a cr (carriage return) every so many values.

Thanks for clearing that up. Bummer, i was hoping for a bug :). I wonder how this works with jit.spill/fill though, they too pass their messages as lists.

Thanks for your suggestion but this will not really help in the setup as it is now since it needs to pass the list at once. I guess it's back to the mxj-drawingboard. :(

(just curious; why are there (still) limits to this. Somehow connected to the same limitations existent in ints/floats?)

Thanks for clearing that up. Bummer, i was hoping for a bug :). I wonder how this works with jit.spill/fill though, they too pass their messages as lists. 

(just curious; why are there (still) limits to this. Somehow connected to the same limitations existent in ints/floats?)


hey frid, the cr solution doesn't help with fileout. maybe you could really collect single ints in an internal array. then it could take another command like "write" or so to confirm everything has been send and than write the file. too bad that rather simple things so often end up in workarounds with max.

"maybe you could really collect single ints in an internal array. then it could take another command like "write" or so to confirm everything has been send and than write the file."

This is exactly the idea, yes. However as you've mentioned it's always easier said than done. For example i've been testing the principle (create array, store incoming ints, bang to print in the maxwindow) and it does compile however when i test it i get errors in the maxwindow?

Anyway thanks for your suggestion and gradually we'll get there...

    private static final String[] INLET_ASSIST = new String[]{

    private static final String[] OUTLET_ASSIST = new String[]{

        declareInlets(new int[]{DataTypes.ALL});

        declareOutlets(new int[]{DataTypes.ALL});

        setInletAssist(INLET_ASSIST);

        setOutletAssist(OUTLET_ASSIST);

This is exactly the idea, yes. However as you've mentioned it's always easier said than done. For example i've been testing the principle (create array, store incoming ints, bang to print in the maxwindow) and it does compile however when i test it i get errors in the maxwindow? 

	private static final String[] INLET_ASSIST = new String[]{
		"inlet 1 help"
	};
	private static final String[] OUTLET_ASSIST = new String[]{
		"outlet 1 help"
	};

	public arrai(Atom[] args)
	{
		declareInlets(new int[]{DataTypes.ALL});
		declareOutlets(new int[]{DataTypes.ALL});

		setInletAssist(INLET_ASSIST);
		setOutletAssist(OUTLET_ASSIST);

	for (int i=0;i
	b = bitt[i];
	post("b");
		}
	}

	public void inlet(int i)
	{
	count+=1;
	bitt[count] = i;
	}
}


[text]-bug?