JASS, Just Another Synth...Sort-of, codename: Gemini (UPDATED TO V-1.0.1)

jass-v1.0.1( esp with midi fixes).zip

1.0.1-CHANGES:

• Fixed issues with midi routing, re the mode selector (mentioned below)
• Upgraded the midi mode "fetch" abstraction to be less granular
• Fix (for midi) so changing cc["14","15","16"] to "rnd" outputs a random wave (It has always done this for non-midi.)
• Added a midi-mode-tester.pd (connect PD's midi out to PD's midi in to use it)
• Upgrade: cc-56 and cc-58 can now change pbend-cc and mod-cc in all modes
• Update: the (this) readme

INFO: Values setting to 0 on initial cc changes is (given midi) to be expected.

JASS is a clone-based, three wavetable, 16 voice polyphonic, Dual-channel synth.

With...

• The initial, two wavetables combined in 1 of 5 possible ways per channel and then adding those two channels. Example: additive+frequency modulation, phase+pulse-modulation, pulse-modulation+amplitude modulation, fm+fm, etc
• The third wavetable is a ring modulator, embedded inside each mod type
• 8 wave types, including a random with a settable number of partials and a square with a settable dutycycle
• A vcf~ filter embedded inside each modulation type
• The attack-decay-release, cutoff, and resonance ranges settable so they immediately and globally recalculate all relevant values
• Four parameters /mod type: p1,p2, cutoff, and resonance
• State-saving, at both the global level (wavetables, env, etc.), as well as, multiple "substates" of for-each-mod-type settings.
• Distortion, reverb
• Midiin, paying special attention to the use of 8-knob, usb, midi controllers (see below for details)
• zexy-limiters, for each channel, after the distortion, and just before dac~

Instructions

Requires: zexy

for-entire-state

• O: Open preset. "default.txt" is loaded by...default
• S: Save preset (all values incl. the multiple substates) (Note: I have Not included any presets, besides the default with 5 substates.)
• SA: Save as
• TEST: A sample player
• symbol: The filename of the currently loaded preset
• CL: Clear, sets all but a few values to 0
• U: Undo CL
• distortion,reverb,MASTER: operate on the total out, just before the limiter.
• MIDI (Each selection corresponds to a pgmin, 123,124,125,126,127, respectively, see below for more information)
  • X: Default midi config, cc[1,7,8-64] available
  • M: Modulators;cc[10-17] routed to ch1&ch2: p1,p2,cutoff,q controls
  • E: Envelopes; cc[10-17] routed to filter- and amp-env controls
  • R: Ranges; cc[10-17] routed to adr-min/max,cut-off min/max, resonance min/max, distortion, and reverb
  • O: Other; cc[10-17] routed to rngmod controls, 3 wavetypes, and crossfade
  • symbol: you may enter 8 cc#'s here to replace the default [10-17] from above to suit your midi-controller's knob configuration; these settings are saved to file upon entry
• vu: for total out to dac~

for-all-mod-types

• /wavetable
  • graph: of the chosen wavetype
  • part: partials, # of partials to use for the "rn" wavetype; the resulting, random sinesum is saved with the preset
  • duty: dutycycle for the "du" wavetype
  • type: sin | square | triangle | saw | random | duty | pink (pink-noise: a random sinesum with 128 partials, it is not saved with the preset) | noise (a random sinesum with 2051 partials, also not saved)
• filter-env: (self-explanatory)
• amp-env: (self-explanatory)
• rngmod: self-explanatory, except "sign" is to the modulated signal just before going into the vcf~
• adr-range: min,max[0-10000]; changing these values immediately recalculates all values for the filter- and amp-env's scaled to the new range
• R: randomizes all for-all-mod-types values, but excludes wavetype "noise"; rem: you must S or SA the preset to save the results
• U: Undoes R

for-each-mod-type

• mod-type-1: (In all cases, wavetable1 is the carrier and wavetable2 is the modulator); additive | frequency | phase | pulse | amplitude modulation
• mod-type-2: Same as above; mod-type-2 May be the same type as mod-type-1
• crossfade: Between ch1 and ch2
• detune: Applied to the midi pitch going into ch2
• for-each-clone-type controls:
  • p1,p2: (self-explanatory)
  • cutoff, resonance: (self-explanatory)
• navigation: Cycles through the saved substates of for-each-mod-type settings (note: they are lines on the end of a [text])
• CP: Copy the current settings, ie. add a line to the end of the [text] identical to the current substate
• -: Delete the current substate
• R: Randomize all (but only a few) substate settings
• U: Undo R
• cut-rng: min,max[0-20000] As adr-range above, this immediately recalculates all cutoff values
• res-rng: min,max[0-100], same as previously but for q
• pbend: cc,rng: the pitchwheel may be assigned to a control by setting this to a value >7 (see midi table below for possibilities); rng is in midi pitches (+/- the value you enter)
• mod-cc: the mod-wheel may be assigned to a control [7..64] by setting this value

midi-implementation

cc - basic (for all midi-configs)

cc - "X" mode/pgmin=123

cc - Modes M, E, R, O

Jass is designed so that single knobs may be used for multiple purposes without reentering the previous value when you turn the knob, esp. as it pertains to, 8-knob controllers.

Thus, for instance, when in Mode M(pgm=124) your cc send the signals as listed below. When you switch modes, that knob will then change the values for That mode.

In order to do this, you must turn the knob until it hits the previously stored value for that mode-knob.

After hitting that previous value, it will begin to change the current value.

cc - Modes M, E, R, O assignments

Where [10..17] may be the midi cc #'s you enter in the MIDI symbol field (as mentioned above) aligned to your particular midi controller.

In closing

If you have anywhere close to as much fun (using, experimenting with, trying out, etc.) this patch, as I had making it, I will consider it a success.

For while an arduous learning curve (the first synth I ever built), it has been an Enormous pleasure to listen to as I worked on it. Getting better and better sounding at each pass.

Rather, than say to much, I will say this:

Enjoy. May it bring a smile to your face.

Peace through love of creating and sharing.

Sincerely,
Scott

@RayManiac It will not be "localhost".
Localhost means "on the same computer".

You will need to know the IP address of the computer you are sending to and then connect with a message like [connect 198.168.1.23 1000( although as @ddw_music says ports are reserved by so many applications that you really should use a port above 8000.

So [connect 192.168.1.23 8499( .......for example.
And [netreceive] set to receive on port 8499.

You really should set the IP address for the remote computer to "static" and not rely on DHCP.
Next time it joins the network it might be given a different address by the DHCP and then your connection will of course fail.
Go to the network settings on the remote computer interface (wireless or Ethernet depending on what you are using) and set a static address. Look at your router web page and see what range of addresses DHCP will assign. Usually it is 192.168.1.50 to 192.168.1.100.
So as to be sure of no conflict set the remote computer to an address outside the range.... 192.168.1.110 for example.

Only ever change the last of the four numbers though or you will be setting an address outside the subnet of the router.
David.

@oscarsantis
NetPd could be a solution if you have a local server running.
But if you don't?

When connecting on a local network there is no problem because security is relaxed for communications on your private network.
For connections to the outside world though, your firewall and your router settings are involved.
For UDP and TCP there are small differences.

UDP is a "one way" protocol. Data is sent without any confirmation that it has arrived correctly.
For OSC that is usually fine as there is usually a flow of messages (as a fader is moved for example) and if one message is dropped it does not matter much.

TCP waits for a confirmation message to be returned, and so it is a "two way" protocol.
The data is always correct, but timing can suffer when data has to be resent.

(((A remote computer address is not something like 192.168.1 35 (a reserved private network address).
It will be something like 133.92.158.230......... the address set by the internet service provider (ISP) for your router.
That works because there are never any direct incoming communications unless you are running a server. That is another can of worms though.
Any incoming connection has been set up by your computer (browser, email etc.) which has told the remote sever how to get back in touch....... and opened the ports to allow it to do so.
See below.......)))

Your firewall will need to allow Pd to send data over the public network..... so check your firewall settings.
It is usually possible to restrict the port range so as to increase security.
But sending is not dangerous. It is incoming data that the router protects you from.

Your router will need to be set to allow an incoming connection for the port that you are using to receive from the remote computer.
Look for "port forwarding" on your router web page. Usually there is some help on the page.
You need to "forward" the port on your computer that the remote computer will be trying to connect to.
You have to set the port and the local IP address of your computer....... so you should fix (static address) the local IP address of your computer and not rely on DHCP because if the address changes it will not be found.

The remote computer cannot use your local IP address..... it will just look for it on its own local network.
It needs to send to the port........ at the web IP address of your router...... set by your ISP.
There are browser tools that will tell you your web IP address....... just a google search "what is my IP" will probably do that.
You might need to tell your ISP that you want your IP fixed..... another can of worms.

All of that is going to apply to the remote computer and its router too.
And of course you need to know the web IP address of the remote router (again...... set by its ISP) so as to send to that address and not the local IP address of the remote computer.
David.

@jameslo one tick is 64 samples in Pd..
Actually this is a much more detailed and understandable explanation......chapter 2.0........ http://pdpatchrepo.info/hurleur/multiprocessing.pdf
David.

Yes and a topic that I like very much.
We're in 2020! Like I always say, we sent a spacecraft to the moon with a 2.048 MHz computer

@cheesemaster said:

-Ubuntu Studio, maybe an RME PCI card

Why RME PCI, you can find good external soundcard, I guess it depends on the computer that you will choose (more on that later). Yes I like Ubuntu Studio, good choice.

-Really only doing audio (oscillators, arrays, filtering, delays) No graphics.

Perfect, start pd with -rt -nogui
Use [pd~] only if topping 100% CPU (pd is single thread).

-Keeping the the machine quiet (low fan noise) is VERY important.

Fanless is possible, again depending on the computer you choose.

What CPU specs matter most for common audio and MIDI tasks in PD? Number of cores? Thread count? Clock speed?

Clock speed = lowest latency (you can push jack to buffer 64) without xruns. If you are not playing live (for example using ADC) you don't need low latency configuration (I am lucky and not very good at detecting latency, my setup is around 38ms (round-trip). You can detect latency using jack_iodelay.

RAM is important if you want to load samples in PD in advance (avoiding glitches).

NVMe SSD if you can.

If I run other apps (VCV rack, Carla, various Jack plugins) will those processes distribute to the other Cores?

Yes, again Pd is single thread. Others are usually better (GUI on a separated thead for example).

Does Pd benefit from a more powerful GPU card? Or will there be no difference if I use the GPU embedded in the CPU? Is it different if I launch Pd without the gui? (-nogui)

If you don't use Gem you don't need a dedicated GPU card.

Here's some ideas for you, I've been building some setup over the years:

Theremin à crayon:

Using a Surface Pro 3 running Ubuntu Studio with a "old" USB 1.1 sound card. Heavy patch using lots of software : Bitwig, SooperLooper, Guitarix and of course PD. Midi (PD), OSC (Bitwig, SooperLooper). Very quiet but the Surface gets hot (fans are kind of quiet like a good laptop).

Heavybox:
https://www.workinprogress.ca/projects/heavy-box/

Similar setup, a quiet PC using a big heat sink and a overrated power supply so the fan never start. Noctura fan on the side (expensive but quiet). Old soundcard (firewire) but I can do low latency. 8 ins/8 outs.

Biscuit box computer:
https://www.workinprogress.ca/biscuit-box-computer/

Mini-pc not quiet, not very fast in this case a cheap usb soundcard (you know +- 8$ barely better than the embedded one).

Phimatics:

A raspberry pi 2 with wolfson audio card. Using only PD with Alsa, I am getting very good result (low latency) quiest setup. But of course I need to be careful with the CPU.

JAS:

Working on a new project, I found this midi keyboard in the trash / snow. I will put Khadas VIM version 1 (ARM) with a BEHRINGER UCG102 (usb soundcard for guitar). Quiet, no fan can be run on a battery (5V). Will post the project when over.

Lattepanda:
Never worked with it, but looks very powerful. There's a price tag. Maybe for the next project.

Cheers

Yep.. You can use comport. It be posible comunicate Pd and arduino.

Drymonitis have nice documentation to do that.

The tutorial "Arduino for PD'ers" is a good start: http://drymonitis.me/code/

He has a excelent book "Digital Electronics for Musicians" if you are interested you can try it to.

@Nicolas-Danet said:

control messages and compute audio vectors of the DSP graph are interleaved operations. The internal audio vector size is 64.

[64][control][64][control][64][control][64][control]

Ok, i see.
But I read control messages are first, then audio. f.e. [loadbang] is proceeded before an upcoming audio-block.
And [vline~] is calculated and "drawn" before and "modulating" the *following * audio blocks.

[control][64][control][64][control][64][control][64]

What's happen in a 1 sample reblocked subpatch? In short, instead of compute 1 vector of 64 samples, it computes 64 times following a vector of 1 sample.

And there is no way to change this interval rate of 64?
Is upsampling in a subpatch increasing the computation time-interval of control-messages?

The tricky stuff with real time audio is not to do the things fast, but do things fast at the right time. Wait the sound in, deliver the sound out, compute the next sound and wait. When i benchmark my fork for instance, most of the time is spent in sleeping!

I see. In the analog world it is very different. This is why we have the buffer-latency in digital everywhere:

...incoming audio-samples in blocks, computation, audio out, and again...

And the control-domain every 64 samples.
For me as "user" of PD this is confusing.
So every object with a [v ...] will be sampleaccurate on point in upcoming audio-blocks, as long as it is not needed more often then 64 samples later!??? i.e. as long it is not starting several times in a smaller interval then 64 samples?

@ingox If you are looking for source code for any old extended externals they are all in https://sourceforge.net/projects/pure-data/files/pd-extended/0.43.4/Pd-extended_0.43.4-source.tar.bz2/download

Worth grabbing a copy while it remains available.
All the "makefile"s are included.
Useful for compiling externals for 64-bit (when they work).

I have seen the sort message almost hidden in a subpatch in 12-tut.pd in a tutorial on scalars here...... https://puredata.info/community/projects/convention04/lectures/tk-barknecht/tut.tgz

and it is mentioned (again... sort of.... with no explanation of the message call) as a function in Chapter 2.9.1 here...... http://puredata.info/docs/manuals/pd/x2.htm
and so it is also in Pd's \doc\1.manual\x2.htm

Zexy sort below. But it looks like the canvas sort is in g.graph.c.
There is an "if scalar sort" statement in there.
However g.graph.c has been disappeared from 0.49...... so......?
David.
.... sort.c.... (zexy)

In/* 
 *  sort :  sort a list of floats
 *
 * (c) 1999-2011 IOhannes m zmölnig, forum::für::umläute, institute of electronic music and acoustics (iem)
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2
 * of the License, or (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License along
 * with this program.  If not, see <http://www.gnu.org/licenses/>.
 */

#include "zexy.h"

/* ------------------------- sort ------------------------------- */

/*
  SHELL SORT: simple and easy
*/

static t_class *sort_class;

typedef struct _sort
{
  t_object x_obj;

  int bufsize;
  t_float *buffer;
  t_int   *indices;

  int ascending;

  t_outlet*indexOut, *sortedOut;
} t_sort;


static void sort_dir(t_sort *x, t_float f)
{
  x->ascending = (f < 0.f)?0:1;
}

static void sort_buffer(t_sort *x, int argc, t_atom *argv)
{
  int n = argc;
  t_float *buf;
  t_atom *atombuf = argv;

  if (argc != x->bufsize) {
    if (x->buffer) freebytes(x->buffer,  x->bufsize * sizeof(t_float));
    if (x->indices)freebytes(x->indices, x->bufsize * sizeof(t_int));

    x->bufsize = argc;
    x->buffer = getbytes(x->bufsize * sizeof(t_float));
    x->indices = getbytes(x->bufsize * sizeof(t_int));
  }

  buf = x->buffer;
  while (n--){
    *buf++ = atom_getfloat(atombuf++);
    x->indices[n] = n;
  }
}

static void sort_list(t_sort *x, t_symbol *s, int argc, t_atom *argv)
{
  int step = argc, n;
  t_atom *atombuf = (t_atom *)getbytes(sizeof(t_atom) * argc);
  t_float *buf;
  t_int   *idx;

  int i, loops = 1;

  sort_buffer(x, argc, argv);
  buf = x->buffer;
  idx = x->indices;

  while (step > 1) {
    step = (step % 2)?(step+1)/2:step/2;

    i = loops;
    loops += 2;

    while(i--) { /* there might be some optimization in here */
      for (n=0; n<(argc-step); n++) {
        if (buf[n] > buf[n+step]) {
          t_int   i_tmp = idx[n];
          t_float f_tmp = buf[n];
          buf[n]        = buf[n+step];
          buf[n+step]   = f_tmp;
          idx[n]        = idx[n+step];
          idx[n+step]   = i_tmp;
        }
      }
    }
  }

  if (x->ascending) 
    for (n = 0; n < argc; n++) SETFLOAT(&atombuf[n], idx[n]);
  else
    for (n = 0, i=argc-1; n < argc; n++, i--) SETFLOAT(&atombuf[n], idx[i]);

  outlet_list(x->indexOut , gensym("list"), n, atombuf);

  if (x->ascending) 
    for (n = 0; n < argc; n++) SETFLOAT(&atombuf[n], buf[n]);
  else
    for (n = 0, i=argc-1; n < argc; n++, i--) SETFLOAT(&atombuf[n], buf[i]);
  outlet_list(x->sortedOut, gensym("list"), n, atombuf);


  freebytes(atombuf, argc*sizeof(t_atom));
}

static void *sort_new(t_floatarg f)
{
  t_sort *x = (t_sort *)pd_new(sort_class);
  x->ascending = (f < 0.f)?0:1;

  x->sortedOut=outlet_new(&x->x_obj, gensym("list"));
  x->indexOut=outlet_new(&x->x_obj, gensym("list"));

  x->bufsize = 0;
  x->buffer = NULL;

  inlet_new(&x->x_obj, &x->x_obj.ob_pd, gensym("float"), gensym("direction"));

  return (x);
}

static void sort_help(t_sort*x)
{
  post("\n%c sort\t\t:: sort a list of numbers", HEARTSYMBOL);
}
void sort_setup(void)
{
  sort_class = class_new(gensym("sort"), (t_newmethod)sort_new, 
                         0, sizeof(t_sort), 0, A_DEFFLOAT,  0);
  
  class_addlist    (sort_class, sort_list);
  class_addmethod   (sort_class, (t_method)sort_dir, gensym("direction"), A_DEFFLOAT, 0);
  class_addmethod(sort_class, (t_method)sort_help, gensym("help"), A_NULL);

  zexy_register("sort");
}
`

Apologies for cross-postings

Fifth Annual Web Audio Conference - 2nd Call for Submissions

https://www.ntnu.edu/wac2019

The fifth Web Audio Conference (WAC) will be held 4-6 December, 2019 at the Norwegian University of Science and Technology (NTNU) in Trondheim, Norway. WAC is an international conference dedicated to web audio technologies and applications. The conference addresses academic research, artistic research, development, design, evaluation and standards concerned with emerging audio-related web technologies such as Web Audio API, Web RTC, WebSockets and Javascript. The conference welcomes web developers, music technologists, computer musicians, application designers, industry engineers, R&D scientists, academic researchers, artists, students and people interested in the fields of web development, music technology, computer music, audio applications and web standards. The previous Web Audio Conferences were held in 2015 at IRCAM and Mozilla in Paris, in 2016 at Georgia Tech in Atlanta, in 2017 at the Centre for Digital Music, Queen Mary University of London in London, and in 2018 at TU Berlin in Berlin.

The internet has become much more than a simple storage and delivery network for audio files, as modern web browsers on desktop and mobile devices bring new user experiences and interaction opportunities. New and emerging web technologies and standards now allow applications to create and manipulate sound in real-time at near-native speeds, enabling the creation of a new generation of web-based applications that mimic the capabilities of desktop software while leveraging unique opportunities afforded by the web in areas such as social collaboration, user experience, cloud computing, and portability. The Web Audio Conference focuses on innovative work by artists, researchers, students, and engineers in industry and academia, highlighting new standards, tools, APIs, and practices as well as innovative web audio applications for musical performance, education, research, collaboration, and production, with an emphasis on bringing more diversity into audio.

Keynote Speakers

We are pleased to announce our two keynote speakers: Rebekah Wilson (independent researcher, technologist, composer, co-founder and technology director for Chicago’s Source Elements) and Norbert Schnell (professor of Music Design at the Digital Media Faculty at the Furtwangen University).
More info available at: https://www.ntnu.edu/wac2019/keynotes

Theme and Topics

The theme for the fifth edition of the Web Audio Conference is Diversity in Web Audio. We particularly encourage submissions focusing on inclusive computing, cultural computing, postcolonial computing, and collaborative and participatory interfaces across the web in the context of generation, production, distribution, consumption and delivery of audio material that especially promote diversity and inclusion.

Further areas of interest include:

• Web Audio API, Web MIDI, Web RTC and other existing or emerging web standards for audio and music.
• Development tools, practices, and strategies of web audio applications.
• Innovative audio-based web applications.
• Web-based music composition, production, delivery, and experience.
• Client-side audio engines and audio processing/rendering (real-time or non real-time).
• Cloud/HPC for music production and live performances.
• Audio data and metadata formats and network delivery.
• Server-side audio processing and client access.
• Frameworks for audio synthesis, processing, and transformation.
• Web-based audio visualization and/or sonification.
• Multimedia integration.
• Web-based live coding and collaborative environments for audio and music generation.
• Web standards and use of standards within audio-based web projects.
• Hardware and tangible interfaces and human-computer interaction in web applications.
• Codecs and standards for remote audio transmission.
• Any other innovative work related to web audio that does not fall into the above categories.

Submission Tracks

We welcome submissions in the following tracks: papers, talks, posters, demos, performances, and artworks. All submissions will be single-blind peer reviewed. The conference proceedings, which will include both papers (for papers and posters) and extended abstracts (for talks, demos, performances, and artworks), will be published open-access online with Creative Commons attribution, and with an ISSN number. A selection of the best papers, as determined by a specialized jury, will be offered the opportunity to publish an extended version at the Journal of Audio Engineering Society.

Papers: Submit a 4-6 page paper to be given as an oral presentation.

Talks: Submit a 1-2 page extended abstract to be given as an oral presentation.

Posters: Submit a 2-4 page paper to be presented at a poster session.

Demos: Submit a work to be presented at a hands-on demo session. Demo submissions should consist of a 1-2 page extended abstract including diagrams or images, and a complete list of technical requirements (including anything expected to be provided by the conference organizers).

Performances: Submit a performance making creative use of web-based audio applications. Performances can include elements such as audience device participation and collaboration, web-based interfaces, Web MIDI, WebSockets, and/or other imaginative approaches to web technology. Submissions must include a title, a 1-2 page description of the performance, links to audio/video/image documentation of the work, a complete list of technical requirements (including anything expected to be provided by conference organizers), and names and one-paragraph biographies of all performers.

Artworks: Submit a sonic web artwork or interactive application which makes significant use of web audio standards such as Web Audio API or Web MIDI in conjunction with other technologies such as HTML5 graphics, WebGL, and Virtual Reality frameworks. Works must be suitable for presentation on a computer kiosk with headphones. They will be featured at the conference venue throughout the conference and on the conference web site. Submissions must include a title, 1-2 page description of the work, a link to access the work, and names and one-paragraph biographies of the authors.

Tutorials: If you are interested in running a tutorial session at the conference, please contact the organizers directly.

Important Dates

March 26, 2019: Open call for submissions starts.

June 16, 2019: Submissions deadline.

September 2, 2019: Notification of acceptances and rejections.

September 15, 2019: Early-bird registration deadline.

October 6, 2019: Camera ready submission and presenter registration deadline.

December 4-6, 2019: The conference.

At least one author of each accepted submission must register for and attend the conference in order to present their work. A limited number of diversity tickets will be available.

Templates and Submission System

Templates and information about the submission system are available on the official conference website: https://www.ntnu.edu/wac2019

Best wishes,
The WAC 2019 Committee

Hi!
I have a weird problem. I am delevoping a patch on a raspberry Pi 2 with Raspbian Jessie and Pd 0.49.
A few days ago, I worked a little bit on the patch. Everything was working fine.
Today, i wanted to open the patch, but I get this red Tcl error in the pd console:

(Tcl) UNHANDLED ERROR: extra characters after close-brace
while executing
"pdtk_text_new .x20d7230.c {.x20d7230.t22b35e0 obj text} 833.000000 245.000000 {<&ì°<=«¯<|®<»æ­<"­<è˫<ïª<Bª<|o©<úæ§< ("uplevel" body line 284)
invoked from within
"uplevel #0 $docmds"

Above this error message, I get a lot of "couldn't create" errors like this:

<&ì°<=«¯<|®<»æ­<"­<è˫<ïª<Bª<|o©<úæ§<ۦ<ƒ1¦<<õ¤<Ìa£<3 ¢<M¡<ëŸ<bUŸ<rٞ<ÿ7<V•›<Œ§š<ks™<~—<ù–<6v•<¥“<\\;ë‘< ·<× <¶úŽ<ݍ<˜­‹<ƥŠ<Ñýˆ<ó‡<d« <¶¸„<‡Pƒ<_º<\}€<?\}<QWz<&œw<\}Mu<%‹r<\\,Ro<wôk<Si<t!f<ŽÔb<Μ_<å-\\\\\\\\<û4X<bT<MlR<ÅHP<%ûL<¯ŸH<KfE<„ŸC<ÏA<ø¯=<K>:< 6<٦2<³v/<+Â\\\\\\,<ª+*<êw&<âH"<ùÜ<áÀ<Ć<V®<ŒH<½õ<ûâ<¦( <!F<¤Ò<Vºþ\\;kÊø\\\\\\;¬ó\\\\\\;—åí\\\\\\;«Bç\\\\\\;áß\\\\\\;ï\\\\\\,Ö\\\\\\;V²Î\\\\\\;-É\\\\\\; ÎÂ\\\\\\;[å»\\\\\\;ÿµ\\\\\\;§N°\\\\\\;k©\\\\\\;yآ\\\\\\;P\\\\\\;d#–\\\\\\;"5‘\\\\\\;]†‹\\\\\\;Ԇ„\\\\\\;|\;=ùq\\\;ýRf\\\;äYT\\\;ß%J\\\;}RB\\\;6\\\;·(\\\;”•\\\;¿ç\\\;˜( \;àð:š•Ì:sB²:UŠ:\\\\ސ:›.}:&àA:<:Ҵè9L†9ë=P8š¹Â& ¹äºD‚.º&ýQº b b
... couldn't create

Do you have any idea what could wrong? Thank you very much,
Jakki