Okay! I thought I was done... So I cleaned up the patch.
Since then, I realize my OSC commands to the lighting board aren't working

I opened up the version of the patch from 2023 that worked, and I realized that I was using the [sendOSC] object.
So mr peach I think? For some reason I can't get the sendOSC object to work on the pi... But I think I have other parts of Mrpeach external working like packOSC. The old version of the patch ran on windows, which isn't as hard (for me) to get the mr peach patch working.

Here's the current version of the patch-
on-air-light-kmtr-v5-OSC.pd

I was SO ready to set it all up but I might have to come back to this tomorrow.
I figure it's still possible to use [netsend -u -b] since we did it with the X32...
But yeah, it's not working from what I tried.

It's a colorsource AV 20 board.. There's an IP, then an OSC IP, a receive port, and a send port. The netmask is 255.255.0.0 which is weird.. But I don't want to change it because we use a streamdeck to send OSC commands to the board and they work. I did change it for a minute and didn't see anything different.

@raynovich said:

Does ofelia take over the "terminal" or some other function for Pure Data if created?

TL;DR Probably the best solution is for you to construct the commands with full paths, pointing exactly where you want, and do not rely on the current working directory.

I.e. not cd xxx/yyy/zzz && ls, but ls xxx/yyy/zzz.

Why?

"Shell" functions (as I understand it -- maybe it's different in some programming environments, but this is my observation) generally don't persist their state.

That is, if you open a terminal window, there is one shell, and every command operates on the same shell. cd changes the current working directory of the shell, and the next command remembers the new cwd.

An object like [shell] is like opening a new terminal window for every command. Every invocation starts from scratch. So you should not expect it to work if you ask shell to first cd, then ls. (You said this worked, but I was not able to get that behavior on my machine.)

SuperCollider has a couple of ways to do it that illustrate the issues involved.

"ls".unixCmd;  // user home

"cd tmp".unixCmd;  // no output, OK

"ls".unixCmd;  // still user home

The cd did not affect the second ls -- because it's like: terminal window 1, ls; terminal window 2, cd; terminal window 3, ls and why would you expect window 2 to affect the behavior of window 3?

Many shells, when parsing the typed input, can handle a series of commands separated by &&:

"cd tmp && ls".unixCmd;  // lists ~/tmp, OK!

But this is a parsing feature. If a backend issues the command in a different way -- as an array of strings, where the first string is the command and the other strings are arguments, one by one -- this bypasses the parser (because the arguments are already parsed into the array), and the && trick no longer works.

"cd tmp && ls".split($ ).postcs.unixCmd;
[ "cd", "tmp", "&&", "ls" ]
(and no `ls` listing)

[shell], as far as I can see, works in this second way. A message like ls tmp works only if it's a list of two symbols. If you try to make it a single command string -- ls\ tmp -- then it fails, because there is no system command named l-s-space-t-m-p. (In SC, "ls tmp".unixCmd runs the command through the shell's parser, which splits a string into command-and-argument. That usage isn't supported in [shell]. Maybe it's supported in [command] but I didn't take a look.)

hjh

Hi, it's been a while, here we go:

RELEASE NOTES:

Hi, it's been almost 8 months without an update and I never took this long!!! So there's a lot of new stuff to cover, because it's not like I've been just sleeping around

The reason for the delay is that I'm trying to pair up with the release cycles of PlugData and we're having trouble syncing up. PlugData 0.9.0 came out recently after a delay of 6 months and we couldn't really sync and pair up then... we had no luck in syncing for a new update now, so now I'm just releasing it up cause enough is enough, and hopefully in the next plugdata release we can sync and offer the same version.

As usual, the development pace is always quite busy and I'm just arbitrarily wrapping things up in the middle of adding more and more things that will just have to wait.

First, I had promised support for double precision. I made changes so we can build for it, but it's not really working yet when I uploaded to deken and tested it. So, next time?

And now for the biggest announcement: - I'm finally and officially releasing a new pack as a submodule, which is a set of abstractions inspired by EuroRack Modules, so I'm thinking of VCV like things but into the Pd paradigm. Some similar stuff has been made for Pd over the years, most notably and famously "Automatonism", but I'm really proud of what I'm offering. I'm not trying to pretend Pd is a modular rack and I'm taking advantage of being in Pd. I'm naming this submodule "Modular EuroRacks Dancing Along" (💩 M.E.R.D.A 💩) and I've been working on it for a year and a half now (amongst many other things I do). PlugData has been offering this for a while now, by the way. Not really fully in sync though.

MERDA modules are polyphonic, thanks to multichannel connections introduced in Pd 0.54! There are 20 modules so far and some are quite high level. I'm offering a PLAITS module based on the Mutable Instruments version. I have a 6-Op Phase Modulation module. A "Gendyn" module which is pretty cool. I'm also including an "extra" module that is not really quite a modular thing at all but fits well called "brane", which was a vanilla patch I first wrote like 15 years ago and is a cool granular live sampler and harmonizer. You'll also find the basics, like oscillators, filters, ADSR envelope and stuff I'm still working on. Lastly, a cool thing is that it has a nice presets system that still needs more work but is doing the job so far.

There are ideas and plans to add hundreds more MERDA modules, let's see when and if I can. People can collaborate and help me and create modules that follow the template by the way

Thanks to Tim Schoen, [play.file~] is now a compiled object instead of an abstraction and it supports MP3, FLAC, WAV, AIF, AAC, OGG & OPUS audio file extensions. A new [sfload] object can import these files into arrays (but still needs lots of more work). There are many other player objects in ELSE that can load and play samples but these don't yet support these new formats (hang in there for the next version update).

Tim also worked on new [pdlink] and [pdlink~] objects, which send control and signal data to/from Pd instances, versions and even forks of Pure Data (it's like [send]/[receive] and [send~]/[receive~], all you need is a symbol, no complicated network or OSC configuration!). And yes, it works via UDP between different computers on the same network. And hell yeah, [pdlink~] has multichannel connections support! By the way, you can also communicate to a [pd~] subprocess. This will be part of ELSE and PlugData of course, and will allow easy communication between PlugData and Pd-Vanilla for instance.

The great pd-lib-build system has been replaced for a 'cmake' build process called 'pd.build' by Pierre Guillot. This was supposed to simplify things. Also, the [sfont~] object was a nightmare to build and with several dependencies that was simply hell to manage, now we have a new and much simpler system and NO DEPENDENCIES AT ALL!!! Some very rare file formats with obscure and seldom sound file extensions may not work though... (and I don't care, most and the 'sane' ones will work). The object now also dumps all preset information with a new message and backwards compatibility broke a bit

I'm now back to offering a modified version of [pdlua] as part of ELSE, which has recently seen major upgrades by Tim to support graphics and signals! This is currently needed in ELSE to provide a new version of [circle] that needed to be rewritten in lua so it'd look the same in PlugData. Ideally I'd hope I could only offer compiled GUI objects, but... things are not ideal

The lua loader works by just loading the ELSE library, no need for anything "else". I'm not providing the actual [pdlua] and [pdluax] objects as they are not necessary, and this is basically the only modification. Since PlugData provides support for externals in lua, if you load ELSE you can make use of stuff made for PlugData with lua without the need to install [pdlua] in Pd-Vanilla.

For next, we're working on a [lua] object that will allow inline scripting and will also work for audio signals (again, wait for the next version)! Also for the next version, I'm saving Ben Wesch's nice 3d oscilloscope made in lua (it'll be called [scope3d~]). There's a lot going on with the lua development, which is very exciting.

As for more actual new objects I'm including, we have [vcf2~] and [damp.osc~]. The first is a complex one pole resonant filter that provides a damping oscillation for a ringing time you can set, the next is an oscillator based on it. There's also the new [velvet~] object, a cool and multichannel velvet noise generator that you can also adjust to morph into white noise.

I wasn't able to add multichannel capabilities to many existing objects in ELSE in this one, just a couple of them ([cosine~] and [pimp~]). Total number of objects that are multichannel aware now are: 92! This is almost a third of the number of audio objects in ELSE. I think that a bit over half might be a reasonably desired target. More multichannel support for existing objects to come in the next releases.

Total number of objects in the ELSE library is now 551!

As for the Live Electronics tutorial, as usual, there are new examples for new objects, and I made a good revision of the advanced filter section, where I added many examples to better explain how [slop~] works, with equivalent [fexpr~] implementations.

Total number of examples in the Live Electronics Tutorial is now 528!

There are more details of course, and breaking changes as usual, but these are the highlights! For a full changelog, check https://github.com/porres/pd-else/releases/tag/v.1.0-rc12 (or below at this post).

As mentioned, unfortunately, ELSE RC12 is not yet fully merged, paired up and 100% synced in PlugData. PlugData is now at version 0.9.1, reaching the 1.0 version soon. Since ELSE is currently so tightly synced to the development of PlugData, the idea is to finally offer a final 1.0 version of ELSE when PlugData 1.0 is out. Hence, it's getting closer than ever Hopefully we will have a 100% synced ELSE/PlugData release when 0.9.2 is out (with a RC 13 maybe?).

Please support me on Patreon https://www.patreon.com/porres
You can follow me on instagram as well if you like... I'm always posting Pd development stuff over there https://www.instagram.com/alexandre.torres.porres/

cheers

ps. Binaries for mac/linux/windows are available via deken. I needed help for raspberry pi

CHANGELOG:

LIBRARY:

Breaking changes:

• [oscope~] renamed to [scope~]
• [plaits~] changed inlet order of modulation inputs and some method/flags name. If a MIDI pitch of 0 or less input is given, it becomes a '0hz'.
• [gbman~] changed signal output range, it is now filtered to remove DC and rescaled to a sane -1 to 1 audio range.
• [dust~] and [dust2~] go now up to the sample rate and become white noise (removed restriction that forced actual impulses, that is, no conscutive non zero values)
• [cmul~] object removed (this was only used in the old conv~ abstraction to try and reduce a bit the terrible CPU load)
• [findfile] object removed (use vanilla's [file which] now that it has been updated in Pd 0.55-0)
• [voices] swapped retrig modes 0 and 1, 'voices' renamed to 'n', now it always changes voice number by default as in [poly] (this was already happening unintentionally as a bug when one voice was already taken). The 'split' mode was removed (just use [route], will you?)
• [voices~] was also affected by changes in [voices] of course, such as 'voices' message being renamed to 'n'.
• [sr~]/[nyquist] changed output loading time to 'init' bang
• [sample~] object was significantly redesigned and lots of stuff changed, new messages and flags, added support for 64-bit audio files (Pd 0.55 in double precision and ELSE compiled for 64 bits is required for this). Info outlet now also outputs values for lenght in ms and bit depth.
• [sfont~] uses now a simpler build system and this might not load very very rare and unusual sound formats.

Enhancements/fixes/other changes:

• builds for double precision is now supposedly supported, by the way, the build system was changed from pd-lib-builder to pd.build by Pierre Guillot.
• [play.file~] is now a compiled object instead of an abstraction thanks to Tim Schoen, and it supports MP3, FLAC, WAV, AIF, AAC, OGG & OPUS file extensions.
• Support for double precision compilation was improved and should be working for all objects (not yet providing binaries and fully tested yet by the way).
• The ELSE binary now loads a modified version of [pdlua], but no [pdlua] and [pdluax] objects are provided.
• added signal to 2nd inlet of [rm~].
• fixed 'glide' message for [mono~].
• fixed [voices] consistency check bug in rightmost outlet and other minor bugs, added flags for 'n', 'steal' and offset.
• [gain~] and [gain2~] changed learn/forget shortcut
• [knob] fixed sending messages to 'empty' when it shouldn't, ignore nan/inf, prevent a tcl/tk error if lower and upper values are the same; added "learn/forget" messages and shortcut for a midi learn mechanism.
• [mpe.in] now outputs port number and you can select which port to listen to.
• Other MIDI in objects now deal with port number encoded to channel as native Pd objects. Objects affected are [midi.learn], [midi.in], [note.in], [ctl.in], [bend.in], [pgm.in], [touch.in] and [ptouch.in].
• [pi]/[e] now takes a value name argument.
• [sr~]/[nyquist~] take clicks now and a value name argument.
• fixed phase modulation issues with [impulse~] and [pimp~].
• [cosine~] fixed sync input.
• added multichannel features to [cosine~] and [pimp~].
• [plaits~] added a new 'transp' message and a functionality to allow MIDI input to supersede signal connections (needed for the 'merda' version [see below]), fixed MIDI velocity.
• [pluck~] added a new functionality to allow MIDI input to supersede signal connections (needed for the 'merda' version [see below]).
• 26 new objects, [velvet~], [vcf2~], [damp.osc~], [sfload], [pdlink] and [pdlink~], plus abstractions from a newly included submodule called "Modular Euro Racks Dancing Along" (M.E.R.D.A)! Warning, this is all just very very experimental still, the object are: [adsr.m~], [brane.m~], [chorus.m~], [delay.m~], [drive.m~], [flanger.m~], [gendyn.m~], [lfo.m~], [phaser.m~], [plaits.m~], [plate.rev.m~], [pluck.m~], [pm6.m~], [presets.m], [rm.m~], [seq8.m~], [sig.m~], [vca.m~], [vcf.m~] and [vco.m~] (6 of these are multichannel aware).

Objects count: total of 551 (307 signal objects [92 of which are MC aware] and 244 control objects)!

• 311 coded objects (203 signal objects / 108 control objects
• 240 abstractions (104 signal objects / 136 control objects)

TUTORIAL:

• New examples and revisions to add the new objects, features and breaking changes in ELSE.
• Added a couple of examples for network communication via FUDI and [pdlink]/[pdlink~]
• Section 36-Filters(Advanced) revised, added more examples and details on how [slop~] works.
• Total number of examples is now 528!

@le26muko said:

My bandmate is pushing me to sell it, and I am trying to explain to him that it does not work like that in this community.

yeah, you know your bandmate doesn't know how open source works

So, yeah, what you're asking about is really highly frowned upon I would say. Of course you're free to do it, but it's not something people actually do or something that goes in this community.

On the other hand, this is such a MAX thing to think and do, and if you want that I'd really suggest you worked with that. People over there sell externals, patches and MAX is better at making apps that are actually just patches.

What Pd people do is ask for donations. I do have a patreon by the way
https://patreon.com/porres

I've been doing cool stuff that people really use and find it useful and never thought I could charge for any of that and, of course, I can't live and base all the work that I do with Pd based on how much I make with Patreon, it's not for this that I do what I do... Pd is more about sharing, contributing, doing voluntary work and being "free" (as in speech, not as in beer).

What people that use Pd also do is create an app with libpd or something, do stuff that is based on Pd but it's a standalone thing on its own, and you can sell it in an app store or something...

Check for the license though. Pd's license is permissive, but most etxernals will use GPL, which won't allow you to sell. On the other hand, my stuff has a very permissive license and you can "do whatever the fuck you wanna do" as one of the clauses will say.

All I'd say is, if you make work and you get money and you use my stuff a lot and you like my work and you feel like motivating me, consider donating something via patreon.

I'm not saying that's the case for you exactly, I'm just telling how I stand on all this as to give you an example on the matter.

cheers

@dreamer They are clearly vestigial from when the abstraction's logic was being sorted out and were probably deleted and brought back many times and their deletion or addition often breaking the abstraction for some incomprehensible reason; they served no purpose and you stared at the before and after for an embarrassing amount of time trying to figure out why it works with such a useless operation that does nothing until you finally see the obvious and delete them once and for all. Then you realize you actually needed a [* 0.5] there, so you put it back and nothing works even though a [* 0.5] should not break anything, just decrease volume or something, but nothing works. Back to staring for an embarrassing amount of time. Delete them, still doesn't work. Put them back and make them [* 1], works. More staring. Learn not to tempt providence and call it good enough. Finally realize what is going on and fix the actual problem but really don't want to tempt providence, just want to make music, so leave them. Isn't this the standard pd work flow? I have at least one [* 1] or [+ 0] or the like in most of my patches.

@lacuna said:

For me it is hard to know because information is missing:
This part I don't understand:

and also to trigger this sample as soon as there is something echoing the trigger at a distance inferior of 15cm using a Threshold~ object

but this works already, doesn't it?
In which condition you want the sample to stop?
What kind of sensor?
What is attached to pins 11 and 12?
What data does [adc~ 12] output when moving hand?
Is [print Distance (cm) : ] about correct?
Which Bela tutorial are you referring to?

[rzero~ 1] does some integration, I think. [dac~ 11] outputs ultrasonics? [line~] till 1000 and [adc~ 12] going into [samphold~] measures the time untill the reflected ultrasound is detected or sth like that?

Generally speaking, when developing something it is important to understand what is going on instead of blind copy&paste. And when asking, to provide all information you have to make it easy / possible to answer.

Hello, thanks for taking the time to answer my question, I really appreciate it; and sorry for having missed some important information.

This patch works as it will start playback when I put my hand on the sensor, but it won't stop playback when I remove my hand from the sensor range, and I'm still figuring out how to work this out. When I remove my hand the distance keeps going up, and thus the volume, until it reaches 25cm which is the limit I've put with [min25]. Your fade out patch makes sense but I still need something to bang it when I remove the hand from the sensor, putting a Threshold at 24cm for example kind of works, but it's not completely natural; imagine you're at 5cm and remove your hand, so the volume goes up to 24cm and then stops playback...

The sensor is the HC-SR04, pin 11 send triggers to ultrasonics every 60ms, echo receives feedback and sends it to pin 12, which with a time equation calculates distance. What [adc~ 12] outputs is a good question, I try to figure it out myself too, but it doesn't work with normal [print] command, not till it reaches [snapshot~] so then it outputs the distance in cm again. The distance is quite accurate, I think the real distance is a bit longer than the printed in console. The Bela tutorials are the official ones at https://learn.bela.io/tutorials/pure-data/sensors/distance-sensor/

What I've done at the moment is sample holding and snapshotting the distance so it stays in place, so if I want to "stop" the sample I just bring the distance near 0 with my hand very close bringing the volume near 0 and nearly unnoticeable, but the playback starts from the beginning with a [loadbang] is just that at any distance you'll put your hand the volume will go up. This works well in this case as the samples are standing notes, but it would be cooler if it starts from the beginning. I know there is some way to use this sensor as a trigger but I can't find any information.

Hi @oid. After reading your most recent post I think I am starting to get it and I can see the advantages to how you are approaching this. It seems you are modularizing parts of the patch. That's why it would be easier for me to envision this in C++ because i can have a different block of code for different situations. And of course you can get as detailed as you want in each section.

I am going to post what I have so far, even though it doesn't really work very well yet. In folder there is a patch called counterpointtest, and other necessary elements.

For now I am trying out the expr object with two variables. f1 is an incoming scale step, and f2 is an interval between the last two notes.

The patch should generate two notes. The one on the left would be a scale step a musician would input into the patch, and the one on the right would be generated based on some counterpoint rules that will be in the expr object (for now I only have a few to see how everything will work).

The inputs Into the expr are intervals based on a 7 note scale, starting with 0. So 0 = unison, 1 = a 2nd, 2 = a 3rd, 3 = a 4th, 4 = a 5th and 7 = an Octave.

In the f2 inlet of the expr should be the interval between the last 2 notes tested.
What should happen is when a new note is played it’s state of change is tested against the last note played

Ideally what would happen is I would play a note that would be f1, that note would be tested against the previous f1. For example, is the new f1 a scale step higher, or lower, etc. Whatever that difference in the past f1 to the current f1 would go into the expr object f1 inlet.

In the other inlet of the expr object, f2 would be the last interval between the two notes, so a 5th, 4th, 3rd etc.

A new interval should be generated by the expr object and added to the f1 scale step that was played. This new note will be played out of the right side of the patch., and the note selected to be played by the musician will be played on the left side of the patch, generating a two note interval (dyad).

This patch doesn't work so well yet. One reason is that I need to put in every possible combination of intervals and scale steps into the expr. Maybe this is crazy as there are probably a hundred possible ways 2 notes can interact. And on top of that I want some interval combinations to have several possible weighted outcomes. Maybe this is too much work, but If I could do it it might be cool to use.

Anyway, if anyone has time to take a look and let me know if I am approaching this in a way that might work and be practical.

thank you. Nick

counterpointtest.zip

I think I found the problem.

This is my test.
I divide the display into two parts:

-on the left there is Pencil2D (a simple drawing app)
-on the right there is the Pure Data patch

xdotool_test3.pd

By clicking on the bang in pd, a circle is drawn in Pencil2D, at the point of desired (x,y) coordinates.
Very nice.
Note: it also works without the "Windows id" (which isn't there).

So, this happens:

in puredata: it works only introducing a delay > 100ms between "mouse move" and "mouse click". With a delay <100ms it doesn't work.

But...running directly from terminal it also works without delay:

me:~$ xdotool mousemove 600 400 && xdotool click 1

...a circle is drawn istantly, without delay.
How do you explain that in puredata I have to insert a delay > 100ms?

Now, the problem is that...trying with other windows of other "non-drawing" programs, it doesn't always work: the click doesn't always have an effect. I have to understand why. Yet the arrow moves and the arrival window is highlighted (therefore it is active), but the click has no effect.

@oid : about your patch "cursor.pd", I wasn't able to use it for my purpose, but it's so cool... I didn't know it could be done, beautiful.

Bye,
a.

@whale-av said:

we don't know what you have achieved. If you get a chance, please write exactly what you have done for the touchosc layout, the connection, the bridge and pd.
A screenshot of the touchosc editor for the simple array, and a screenshot of the settings in touchosc on the ipad.
Plus whatever else you think will make it clear how you succeeded.

This I can understand. I hope the contents below will shed some light as to what I accomplished and how I accomplished it.

Okay, I'll try to write in an informative way.

When I realized that I couldn't do UDP/TCPIP/OSC things in a simple-enough (for me) way, and I couldn't get them to talk together, and I just wasn't able to conceive of what I was doing wrong, what I ended up doing is this:

1. Create a Grid in TouchOSC limited to 16
2. Set it up so that it sends to midiCH 6, and from CC 41 to CC 56 (i.e., 16 places)
3. figure out what the math was for getting the 0...127 grid to become -2 to 8 or something. (ok I asked ChatGPT for that and it gave me the answers)
4. Create a really hamfisted PD script that takes the 0...127 input from all of those CCs, and slams the modified 0...127 data to the first inlet of a tabwrite, and a hardcoded message with a number to the second inlet of the tabwrite. It looks really bad, and I could've made it better with a spigot or something, but I just wanted it to work quickly and see if I could use it.
5. The Array <-> TouchOSC Grid is one way, there's no communication from PD back to the Grid object to signify which step is being played.

as mentioned above, it looks like absolute trash. i just wanted it to work since had a working day the next day and limited time. i haven't even taken the time to clean it up, or to re-think how it could be simplified so that it doesn't need to look like such a crazy birdnest. (i really detest when my scripts look like this, and prefer to clear them up and use abstractions, but .. it works for now)

it's a simple thing in TouchOSC

and yep I'm still using MIDI only to talk to TouchOSC Bridge app running on macOS (iPad sends via MIDI to TouchOSC Bridge, which becomes a midiport in PD that i've mapped my PD script to talk to)

so, now that i have this "well it'll do in a pinch, kinda works, aargh but works" type thing, i feel like it would be really cool to comprehend UDP OSC but if it requires manually (and this'd be in the heat of the moment, just before a gig starts) figuring out IP addresses for both the iPad and macOS and changing a PD script just before the gig starts, could be quite nervewracking. But since the grid highlights based on which step it is running in, that would be pretty amazing.

This is a continuation to the issue I wanted to solved in this topic. It just went to different places so I though I will open a new topic to this problem I'm facing.

I have a pd patch that doing some audio playback reading some files from buffer. I'm running it on my Pi4.

I wanted it to start on boot every time and to be able to reset itself if crashing for some reason.
I was suggested to use that service script:

[Unit]
Description=My PureData service

[Service]
Type=simple
LimitNOFILE=1000000
ExecStart=/usr/bin/puredata -nogui  -open /home/pi/mypatch.pd
WorkingDirectory=/home/pi
User=pi
Group=pi
Restart=always
# Restart service after 10 seconds if service crashes
RestartSec=10

[Install]
WantedBy=multi-user.target

The above was working great using the built in 3.5mm audio jack.
I then bought UGREEN USB audio interface as I was facing with some poor audio quality at the output.

I set the audio preference in PD to choose the USB Audio Interface as the output.

When I boot the Pi I'm getting this error from the service (see picture)

If I'm typing sudo systemctl restart my_puredata.service the PD patch is back to work just fine. No Alsa error, but on the initial boot it is not working.

Any idea why this happen when using the USB AudioInterface? anything I can do in order to make it work?

So If to conclude:

When I start the same pd patch using the same service script but without a USB audio interface is working just fine.

When I start the same pd patch with the USB audio interface but using the autostart file:

sudo nano /etc/xdg/lxsession/LXDE-pi/autostart

Is also working just fine.

But the combination of the USB audio interface and the service script is just not working.

Thanks for any help.